<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I forgot about this.<br>I never resolved it.<br>Things seem to work though.<br>?<br><br> - Jay<br><br>> From: jay.krell@cornell.edu<br>> To: hosking@cs.purdue.edu<br>> Date: Tue, 13 Jul 2010 06:38:05 +0000<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] barrier labels?<br>> <br>> <br>> I don't know. There is so much unknown here. It is frustrating and difficult.<br>> We could use an extensive set of test cases.<br>> Or know more about the test cases we do have.<br>> And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not.<br>> <br>> tangent:<br>> <br>> I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat<br>> directory per architecture. I guess it's just a matter of a little code.<br>> It should just skip the few errors that are cross problems, which I should fix anyway.<br>> That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int<br>> if doing a native build, and assert that the results match.<br>> I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3.<br>> Can't ship m3core/libm3 for cross building.<br>> I guess, and I forgot this, I should have used -x for override. Duh.<br>> That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops.<br>> <br>> <br>> - Jay<br>> <br>> ----------------------------------------<br>> > From: hosking@cs.purdue.edu<br>> > Date: Mon, 12 Jul 2010 09:43:01 -0400<br>> > To: jay.krell@cornell.edu<br>> > CC: m3devel@elegosoft.com<br>> > Subject: Re: [M3devel] barrier labels?<br>> ><br>> > Perhaps we just need FORCED_LABEL for these:<br>> ><br>> > /* In a LABEL_DECL, nonzero means this label had its address taken<br>> > and therefore can never be deleted and is a jump target for<br>> > computed gotos. */<br>> ><br>> ><br>> > On 11 Jul 2010, at 23:03, Jay K wrote:<br>> ><br>> > ><br>> > > I still don't see it, in the C++ frontend.<br>> > ><br>> > > There is:<br>> > ><br>> > > void<br>> > > expand_label (tree label)<br>> > > {<br>> > > ...<br>> > > if (DECL_NONLOCAL (label))<br>> > > {<br>> > > ... nonlocal_goto_handler_labels<br>> > > = gen_rtx_EXPR_LIST (VOIDmode, label_r,<br>> > > nonlocal_goto_handler_labels);<br>> > > }<br>> > ><br>> > > but I don't think this works until later.<br>> > ><br>> > > - Jay<br>> > ><br>> > > ----------------------------------------<br>> > >> From: hosking@cs.purdue.edu<br>> > >> Date: Sun, 11 Jul 2010 20:52:25 -0400<br>> > >> To: jay.krell@cornell.edu<br>> > >> CC: m3devel@elegosoft.com<br>> > >> Subject: Re: [M3devel] barrier labels?<br>> > >><br>> > >> No, that code came from 4.x...<br>> > >><br>> > >><br>> > >><br>> > >><br>> > >> On 11 Jul 2010, at 19:41, Jay K wrote:<br>> > >><br>> > >>><br>> > >>> Tony, thanks for the pointer..though I haven't been able to find it yet.<br>> > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time.<br>> > >>><br>> > >>> - Jay<br>> > >>><br>> > >>> ----------------------------------------<br>> > >>>> From: hosking@cs.purdue.edu<br>> > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400<br>> > >>>> To: jay.krell@cornell.edu<br>> > >>>> CC: m3devel@elegosoft.com<br>> > >>>> Subject: Re: [M3devel] barrier labels?<br>> > >>>><br>> > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets.<br>> > >>>><br>> > >>>> On 11 Jul 2010, at 07:46, Jay K wrote:<br>> > >>>><br>> > >>>>><br>> > >>>>> Tony, six years ago you introduce what is now:<br>> > >>>>><br>> > >>>>><br>> > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6<br>> > >>>>><br>> > >>>>><br>> > >>>>> static void<br>> > >>>>> m3cg_set_label (void)<br>> > >>>>> {<br>> > >>>>> ...<br>> > >>>>> if (barrier)<br>> > >>>>> {<br>> > >>>>> ...<br>> > >>>>> {<br>> > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels;<br>> > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels<br>> > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list);<br>> > >>>>> }<br>> > >>>>> ...<br>> > >>>>><br>> > >>>>><br>> > >>>>> I'm not sure what to do here for gcc 4.5.<br>> > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and<br>> > >>>>> deal with it later in compilation.<br>> > >>>>><br>> > >>>>><br>> > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient).<br>> > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone.<br>> > >>>>><br>> > >>>>><br>> > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN.<br>> > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later.<br>> > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests.<br>> > >>>>><br>> > >>>>><br>> > >>>>> Do we have good exception handling tests?<br>> > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg.<br>> > >>>>><br>> > >>>>><br>> > >>>>> I'll poke around more..<br>> > >>>>><br>> > >>>>><br>> > >>>>> - Jay<br>> > >>>>><br>> > >>>><br>> > >>><br>> > >><br>> > ><br>> ><br>> <br> </body>
</html>