[m-dev.] IL foreign types are not being recognised

Jonathan Morgan jonmmorgan at gmail.com
Fri Apr 20 00:22:09 AEST 2007


On 4/16/07, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>
> On Mon, 16 Apr 2007, Jonathan Morgan wrote:
>
> > When attempting to build the latest version of Mercury in the IL
> > grade, I have been getting assertion failures in library functions
> > that use IL foreign types.  Any ideas what the problem might be?  I
> > have included some of the output of make -k install.
>
> There has been a test case (valid/foreign_type_spec) that has
> been failing with the same assertion failure for a while now.
> I briefly looked into a while back but didn't do anything about
> it (I was busy with other things at the time and it didn't seem
> to be a priority.)
>
> I don't remember the specific details but I think the compiler is
> not doing something right when building the optimization interfaces,
> e.g. handle_options doesn't set the options up correctly or something
> along those lines.
>
> > mmc --make-optimization-interface --grade il      --mercury-linkage
> > shared --flags LIB_FLAGS   --flags INTER_FLAGS --allow-stubs
> > --no-warn-stubs  --no-warn-insts-without-matching-type   array
> > Uncaught Mercury exception:
> > Software Error: foreign.m: Unexpected: to_exported_type: no IL type
> > Stack dump not available in this grade.
> > make[2]: *** [array.optdate] Error 1
> > mmc --make-optimization-interface --grade il      --mercury-linkage
> > shared --flags LIB_FLAGS   --flags INTER_FLAGS --allow-stubs
> > --no-warn-stubs     assoc_list
> > Uncaught Mercury exception:
> > Software Error: foreign.m: Unexpected: to_exported_type: no IL type
> > Stack dump not available in this grade.
> > make[2]: *** [assoc_list.optdate] Error 1
> >
> > (Note that assoc_list has no foreign types, just equivalence types).
>
> I think the assertion failure is referring to one of the opt imported
> types here.  (It would be more helpful if the message actually said
> which type.)

The problem seems to be in bitmap.  This would make sense, since the
changes to bitmap are still commented out for the IL backend.  I knew
this was the case, but it didn't occur to me that it would cause
problems in other modules.

I don't think that there is sufficient information in the predicate
for the error message to give the type (though it would be nice).

Jon
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list