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

Mark Brown dougl at cs.mu.OZ.AU
Thu Jan 30 01:11:18 AEDT 2003


On 29-Jan-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 29-Jan-2003, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > On 29-Jan-2003, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > > Can you mail me the test case?
> > 
> > By this I meant the generated .c file you are having the problem with,
> > and the options you used to generate it. I tried compiling the original
> > source a couple of ways, and I can't see any problem with consecutive
> > labels in the generated .c files.
> 
> The labels don't need to be consecutive to exhibit the problem --
> the C compiler is doing duplicate code elimination, so the labels
> only need to point to identical code.

Yes.  Below is some excerpts (with comments added) from the C code generated
for the module I posted earlier.  It was compiled with the release version
installed on hermes, using 'mmc --trace deep --opt-space o'.

/* Begin generated code. */

/* Code to call a/2 in the first disjunct. */

        MR_stackvar(5) = MR_r1;
        MR_r1 = (MR_Integer) 1;
        MR_trace_from_full = MR_TRUE;
        MR_trace_reset_depth(MR_stackvar(3));
        MR_call_localret(MR_STATIC(mercury__o__a_2_0),
                mercury__main_2_0_i11,
                MR_ENTRY(mercury__main_2_0));
MR_define_label(mercury__main_2_0_i11);
        MR_update_prof_current_proc(MR_LABEL(mercury__main_2_0));
        MR_r2 = MR_stackvar(5);
        MR_GOTO_LABEL(mercury__main_2_0_i8);

/* Then a bit later, the code to call a/2 in the second disjunct. */

        MR_r1 = (MR_Integer) 2;
        MR_trace_from_full = MR_TRUE;
        MR_trace_reset_depth(MR_stackvar(3));
        MR_call_localret(MR_STATIC(mercury__o__a_2_0),
                mercury__main_2_0_i13,
                MR_ENTRY(mercury__main_2_0));
MR_define_label(mercury__main_2_0_i13);
        MR_update_prof_current_proc(MR_LABEL(mercury__main_2_0));
        MR_r2 = MR_stackvar(5);
MR_define_label(mercury__main_2_0_i8);
        if (((MR_Integer) MR_r1 != (MR_Integer) 0)) {
                MR_GOTO(MR_ENTRY(MR_do_redo));
        }
        MR_maxfr = (MR_Word *) MR_stackvar(6);
        MR_GOTO_LABEL(mercury__main_2_0_i16);

/* This last label, mercury__main_2_0_i16, points to the 'then' branch. */

/* End generated code. */

The two continuations, labelled *i11 and *i13, do the same thing:
they call the profiling macro, they restore MR_r2 from stack slot 5,
then they execute the code at label *i8 which either does a redo
or jumps to the 'then' branch.  The only difference is that the first
continuation jumps to *i8, whereas the second continuation falls
through into it.

Is it the case that an asm volatile statement will be generated in any
grade where the internal label tables will be used?

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