[M3commit] CVS Update: cm3

[Jay K]

Basically the same as before.

 - Jay

----------------------------------------
> Date: Wed, 2 Jun 2010 20:31:34 +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/06/02 20:31:34
>
> Modified files:
> cm3/m3-sys/m3cc/gcc/gcc/config/: sol2.h
> cm3/m3-sys/m3cc/gcc/gcc/config/sparc/: sparc.h
> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c
>
> Log message:
> significantly remove use of volatile
> Allowing the optimizer to actually do anything
>
> volatile remains on Solaris/sparc32
> probably just need to experiment extensively
>
> volatile remains on all floating point loads,
> quite unfortunate for the scientific computing crowed..
>
> volatile is added to more locals and temporaries
> within functions that call setjmp/vfork
> (setjmp is very common!?)
>
> volatile store after insert_mn, small lame hack,
> because otherwise we have a read before write
>
> a few optimizations are turned off,
> though I did solve the "unit at a time" problem, with TREE_USED
> or so I thought, but no...I had confused "ui" and "vbtkit" packages
>
> prototype marking fault_proc as noreturn
> but then I get a warning that it does return,
> even if I removed the return
>
> Provide and use m3_build_pointer_type that presently is pointless,
> but maybe will mean something in future
> There is a bit to turn off alias analysis.
> pre/fre still crashed. I didn't try vrp, it is
> the most painful to test when it goes wrong, because
> it successfully compiles everything.
>
> Mostly tested on AMD64_DARWIN.
> Needs broader coverage.
> Need to consider the warnings it causes.
> Need to get fault_proc marked noreturn first.
> Could use better for Solaris/sparc32, but machine
> is so slow experimentation is painful.
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: volatile1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100602/903446bc/attachment-0002.txt>