[m-dev.] Bug 321

[Paul Bone]

On Fri, Feb 21, 2014 at 08:58:58PM +1100, Zoltan Somogyi wrote:
> 
> On Fri, 21 Feb 2014 18:16:52 +1100, Paul Bone <paul at bone.id.au> wrote:
> > So I looked at readelf(1) dump of libmer_std.so's symbol table.
> > get_determinism/2 is exported globally and wrap_success_or_failure/2 is
> > exported locally.
> 
> I think you mean to say that wrap_s_or_f is local to its defining object file.
> 
> > Both are declared and defined in the implementation section of the exception
> > module.  So now I want to know why is one being treated differently.
> > 
> > The relevant code seems to be on line 2186 of compiler/intermod.m, where the
> > compiler performs a fixpoint analysis so that it knows what else needs to be
> > opt-exported.  Searching further (line 289) I find should_be_processed/8
> > which appears to determine if a predicate should be opt-exported or not,
> > I'm not sure as comments are scarce.
> > 
> > Is there anyone familiar with this part of the compiler?  My clues are the
> > above, plus wrap_success_or_failure takes a higher order argument and is
> > part of a lambda expression itself, during compilation (in the HLDS) it
> > appears to be partially applied.
> > 
> > One specific question I have is how does the compiler decide between:
> >     + opt-exporting a predicate
> >     + making a predicate available to another module because a caller is
> >       opt-exported and this predicate is otherwise local.
> >     + leaving the predicate local.
> > 
> > I haven't found the code for the second case.
> 
> I think the bug is likely to be precisely the absence of code
>  for the second case.
> 
> I don't think you want to hear this, but I am pretty sure that
> the underlying reason for this bug is that the import_status type
> tries to encode far too many things at once. Some are relevant to
> types; some to unify predicates; some to other preds. Some are
> about location of definition, some are about visibility to Mercury code
> in other modules, some are about visibility to target code in other
> modules, and some are about visibility to submodules. The space
> of possible combinations is very large, but it is not fully covered.
> In this case, an import_status  ought to be able to say
> "this predicate is not callable by code in other Mercury modules,
> but it is called from a local predicate that has been made available
> for inlining by other modules, so its target code needs to be
> accessible from other modules", but it cannot.
> 
> Some years ago, I drew up two proposals for replacements
> for the import_status type. I think there was discussion
> of those proposals on a mailing list (m-dev or m-rev), but
> I am not sure; I am sure that neither proposal was actually
> implemented. Anyway, here are my files containing the two
> proposed sets of types to replace import_status. I think
> replacing import_status with either of these would be
> a significant improvement in the reliability of our handling
> of import and export. Unfortunately, it would also be
> a large amount of work. Someone would have to look
> at all current code that handles values of type import_status,
> and rethink exactly what the right thing to do in each case is.
> We currently have a bunch of utility predicates for testing
> this property or that of an import_status; all those calls
> would have to be looked at again. Most will probably be
> ok (and should be replaceable by simple unifications)
> but some won't.
> 

Hi Zoltan.  I've found your original proposal using these alternative
structures from 2008:

http://www.mercurylang.org/list-archives/reviews/2008-November/013237.html

Here you and Julien agree that the second version is preferred.  I arrived
at this conclusion before I found this thread so I definitly agree.
I'll begin working on this now (it's blocking some other work I need to fix
for MCit).  The main purpose of this e-mail is to share the link above.

One strange thing I'm noticing with this bug is that some people hit it
reliably (like myself, and others, it's not just me!) and some don't hit it
at all (like Julien).  Are any of the compiler's optimisation settings set
based on the host system/gcc version?  Julien, have you tried this in
asm_fast.gc with gcc 4.8 on 64bit Linux?

Thanks.


-- 
Paul Bone