[mercury-users] Re: segfault in hlc.gc when optimise-constructor-last-call is enabled

[Zoltan Somogyi]

On 27-Feb-2011, Michael Day <mikeday at yeslogic.com> wrote:
> $ ./bad
> num_float(
> *** Mercury runtime: caught segmentation violation ***
> cause: address not mapped to object
> address involved: (nil)

This is a different problem from mantis bug 103.

The problem is that at the moment, the hlc backend boxes floats when
they appear as arguments in structures (even on 64 bit platforms), but not
when it passes them as stand-alone arguments. When the optimize constructor
last call optimization transforms the HLDS, it takes the address of a boxed
float, and casts it to be a pointer to an unboxed float. The callee fills in
the pointed-to location with a float, the caller interprets this as a boxed
float i.e. a pointer to a float, and you get a core dump.

The low level backend does not suffer from the problem: if sizeof(double) ==
sizeof(void *), it uses unboxed floats in both places (structures and
arguments); if if they are of different sizes, it uses boxed floats in both
places. The hlc backend tried to generate "more natural" as well as faster
C code by using unboxed floats in arguments regardless of whether floats were
boxed in structures, which they were on 32 bit platforms.

The short term fix, which I am testing now, is to disable the application of
the lcmc optimization in cases where this may happen. I expect to be able
to commit that tomorrow, so it should be in the rotd on friday. This should
make your code work with lcmc, but it will not be able optimize the code
in your test case.

The better fix would be to make floats unboxed in hlc grades as well
if sizeof(double) == sizeof(void *), and to disable the workaround in
that case. That has the additional advantage that it should make G12 code
run significantly faster on current 64 bit platforms. The disadvantage is that
it would take at least several days of work, and I don't have that time
available.

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