[M3devel] barrier labels?

[Jay K]

As well, SOLgnu/SOLsun/SPARC32_SOLARIS when using the gcc 4.5.1 backend crash just after raising an exception. Ugh.
Needs investigation..

 - Jay

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