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

[Mark Brown]

On 28-Jan-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 27-Jan-2003, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> > When compiled with '--opt-space', the following module exposes what appears
> > to be a bug in the cygwin C compiler installed on hermes.  The symptom is
> > that walking up the stack to retrieve the caller's label layout sometimes
> > returns the wrong layout.  Under mdb, the call event for the first call
> > to a/2 reports the calling context as line 11, which is correct.  However,
> > the call event for the second call to a/2 reports the same calling context,
> > when in fact the context should be line 13.
> 
> 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.

I also found that if I modified the C code by replacing a particular MR_GOTO
with the code at the destination of that goto then the correct behaviour
resulted, even though that shouldn't have made any difference.

So I'm not completely certain that it is a compiler bug, but that seems
to me to be the most likely explanation.

> 
> Have you reported the bug to the GCC developers?

No, but I'm happy to if you can confirm that it is indeed a bug in their
compiler.

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
--------------------------------------------------------------------------