[patch] PR30513

Andreas Tobler toa@pop.agri.ch
Thu Jan 25 05:29:00 GMT 2007


Boehm, Hans wrote:
> Is there a spec of what these should do?

I don't know. My take was to get gcc back in bootstrap land for 
sparc-solaris. I found on this way that these two functions, 
read_barrier and write_barrier were not implemented for. So I tried to 
implement them for sparc.

> The patch, taken together with support on other architectures, is quite
> inconsistent.
> 
> I would expect that the 32 and 64 bit variants would need the same kind
> of fences.

As said, I only tried to get it build again. I see that there are 
differences but I didn't investigate further. Also, due to whatever 
reason, this code was not used until this patch comes in. The 
configure.host bit where it tells sparc* to have sysdep_dir=sparc was 
missing until now. So it always used the generic part for sparc.

> It looks like x86-64 and i386 read_barrier is just broken, in that it
> doesn't prevent compiler reordering.
> 
> I would have expected at least the PowerPC write barrier implementation
> to use lwsync.

Hm.

> I'm probably biased, but it seems to me that the atomic_ops package
> (used in gc7) is more coherent here.

:)

Yeah, but there we lack some functions in the sparc-solaris port.

BTW, you got my ppc64 additions for the atomic_ops package ?

Thanks,
Andreas



More information about the Java-patches mailing list