[m-rev.] trivial diff: workaround cygwin C compiler bug

Mark Brown dougl at cs.mu.OZ.AU
Wed Jan 29 11:54:01 AEDT 2003


On 28-Jan-2003, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> On 28-Jan-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > What makes you think this is a bug in the C compiler?
> 
> I inspected the generated C code and couldn't see anything wrong
> with it.  In particular, the parent layout is derived from the value
> in the succip slot, which comes from the value passed to the macro which
> does the call.  For the first disjunct, the code to call a/2 is
> 
>         MR_call_localret(MR_STATIC(mercury__o__a_2_0),
> 		mercury__main_2_0_i11,
> 		MR_ENTRY(mercury__main_2_0));
> 
> and for the second disjunct it is
> 
>         MR_call_localret(MR_STATIC(mercury__o__a_2_0),
> 		mercury__main_2_0_i13,
> 		MR_ENTRY(mercury__main_2_0));
> 
> where the two labels mercury__main_2_0_i11 and mercury__main_2_0_i13 are
> the ones you would expect.  Unfortunately, gdb shows that at the point
> where we call MR_trace_real for the call event of the second call to a/2,
> the stack slot still holds the earlier value, even though the code does
> assign MR_succip to it before that point.  Under linux, the stack slot
> held the expected value at that point.

Wait, I think I see the problem.  We use the code addresses of those labels
to look up the label layout info in a hash table, with the assumption that
different labels will have different code addresses.  In this case,
though, the code pointed to by the two labels happens to be identical,
and the C compiler appears to recognise this and (quite rightly) merge the
two pieces of code into one.  So I think our assumption is wrong.

One way we could avoid that assumption is to store the label layout in
its own stack slot, rather than trying to determine it from the contents
of the succip slot.  On the other hand, perhaps there is an option to
gcc that stops it from merging duplicate code, which we can use when
tracing is enabled.  Any advice?

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list