[patch] PR30513

[Boehm, Hans]

Is there a spec of what these should do?

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.

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.

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

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Andreas Tobler
> Sent: Wednesday, January 24, 2007 4:33 AM
> To: Java Patches
> Subject: [patch] PR30513
> 
> Hello all,
> 
> for details have a look at the PR.
> 
> Here comes my proposal for a patch. It is the easiest one in 
> terms of testing and modifying files.
> 
> Thanks goes to Tom and PinskiA.
> 
> Ok for trunk?
> 
> I'd like a sparc expert to look at the read/write barriers. 
> Are they correct ? Who is one ??
> 
> 
> Andreas
> 
> 2007-01-24  Andreas Tobler  <a.tobler@schweiz.org>
> 
> 	PR libgcj/30513
> 	* configure.host: Add forgottten sysdep_dir to sparc. 
> Add a flag to
> 	libgcj_flags to undefine 'sun' at compile time.
> 	* sysdep/sparc/locks.h (read_barrier): New functions 
> for 32 and 64 bit
> 	Sparc.
> 	(write_barrier): Likewise.
>