[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