[M3commit] CVS Update: cm3

[Jay K]

Not a multiprocessor.
  Still interested in selective volatile?


This all bothers me too.
I don't want volatile. It makes the optimized code terrible.
But I don't want to debug any problem from removing it, beyond compilation failure.


I can try a few things.
This is all wierd. I swear I saw it hang several times.
I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many.


Once I started getting version stamp mismatch, I resorted to using a cross built cm3.
 Out of necessity sort of, but that causes more flucuation of variables.

Let me try again with volatile and see if it is solid.
 Then I'll try with only volatile stores.

I've been trying optimized and unoptimized, and not kept good track of which when.


 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 3 Jul 2010 20:36:20 -0400
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor?
>
> On 3 Jul 2010, at 12:57, Jay Krell wrote:
>
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/07/03 12:57:09
> >
> > Modified files:
> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> >
> > Log message:
> > restore volatile for powerpc and powerpc64 platforms
> > This seems to fix PPC_LINUX hanging.
> > This needs further debugging, but I'm not eager.
> > This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD,
> > PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or
> > nonexistant.
> >
> > Having volatile like has been the very long standing situation though.
> > The result is that the optimizer does basically nothing.
>