[M3commit] CVS Update: cm3

[Jay K]

Drat, this doesn't let it work across the whole tree..


new source -> compiling m3totex.m3
../src/m3totex.m3: In function 'm3totex__Undisplay':
../src/m3totex.m3:210: internal compiler error: in remove_phi_node, at tree-phinodes.c:465
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
  m3_backend => 4
m3cc (aka cm3cg) failed compiling: m3totex.mc
compilation failed => not building program "m3totex"
Fatal Error: package build failed
 *** execution of [<function _BuildGlobalFunction at 0x2526b0>, <function _ShipFunction at 0x2526f0>] failed ***


(normally this would SIGSEGV but I put assertions in)



----------------------------------------
> From: jay.krell at cornell.edu
> To: jkrell at elego.de; m3commit at elegosoft.com
> Date: Sat, 10 Jul 2010 12:29:43 +0000
> Subject: Re: [M3commit] CVS Update: cm3
>
>
> not great but maybe ok for the time being, for a while..
>
> ----------------------------------------
> > Date: Sat, 10 Jul 2010 14:27:27 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/07/10 14:27:27
> >
> > Modified files:
> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> >
> > Log message:
> > use POINTER_PLUS with gcc 4.3 same as with gcc 4.5
> > volatilize any function that calls RTHooks__PushEFrame
> > Therefore enabling "pre" optimization (partial redundancy elimination?)
> > This would probably be cleaner in a few other ways:
> > investigate further why gcc doesn't like the trees we produce for this case
> > have a direct call in the middle end: volatilize_current_function
> > understand (at least) the two variants of try/finally
> > don't volatilize all variables
> > In my one test case though, the finally block doesn't
> > access anything, so only volatilizing what is needed
> > would set us back to really having to understand.
> >
> > And, really, volatile even of certain variables is overkill.
> > You just want be sure they are "homed" prior to function
> > calls that can throw, not at every single use and not
> > before function calls that can't throw.
> >
>