From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11149 invoked by alias); 25 Jan 2007 05:29:15 -0000 Received: (qmail 11136 invoked by uid 22791); 25 Jan 2007 05:29:14 -0000 X-Spam-Check-By: sourceware.org Received: from exsmtp02.agrinet.ch (HELO exsmtp02.agrinet.ch) (81.221.252.201) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Jan 2007 05:29:08 +0000 Received: from smtp.messaging.ch ([10.50.250.214]) by exsmtp02.agrinet.ch with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Jan 2007 06:29:04 +0100 Received: from [192.168.225.5] ([84.73.68.225]) by smtp.messaging.ch with id FHV41W0014rcz700000000; Thu, 25 Jan 2007 06:29:12 +0100 X-IMP: RBL SBL+XBL: 0.00,RBL SPAMCOP: 0.00,RBL SORBS: 0.10,RBL MAPS_ORDB: 0.00,URL RHS: 0.00,URL SURBL: 0.00 Message-ID: <45B84018.70605@pop.agri.ch> Date: Thu, 25 Jan 2007 05:29:00 -0000 From: Andreas Tobler User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Boehm, Hans" CC: Java Patches Subject: Re: [patch] PR30513 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2007-q1/txt/msg00194.txt.bz2 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