[M3commit] CVS Update: cm3

[Tony Hosking]

On 14 Dec 2009, at 10:43, Jay K wrote:

> I know I know. I know exactly the code. I rewrote it, at least once.
> Cross compiling works.
> Native does not.
> It must be the threshold variables in RTCollector.

Yeah, I've been bitten by just that scenario in the past -- those are the earliest use of FP in the run-time linker.  If they are broken you find out quickly.  Can you take a look at the gcc m3cg code for FP?  It worked at one point just fine on native Alpha 64-bit, so should not be too hard to fix.

> I really thought I understood that code.
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Dec 2009 10:38:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> This suggests an m3cg backend compiler problem for floating point on SPARC64.
> 
> On 14 Dec 2009, at 14:40, Jay Krell wrote:
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	09/12/14 14:40:15
> 
> Modified files:
> 	cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 
> 	cm3/m3-libs/m3core/src/unix/: m3makefile 
> Removed files:
> 	cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3 
> 
> Log message:
> 	updates so SPARC64_SOLARIS bootstrap can build
> 	(possible tangent related to getting SPARC64_OPENBSD
> 	to work -- problem apparently with the floating point
> 	constants in RTCollector, such that Behind() is
> 	always TRUE, even for the first allocation, so
> 	access violate trying to garbage collect too
> 	early, when self is still NULL)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091214/c70bd4f2/attachment-0002.html>