From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25211 invoked by alias); 2 Apr 2011 07:56:26 -0000 Received: (qmail 25201 invoked by uid 22791); 2 Apr 2011 07:56:25 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Apr 2011 07:56:21 +0000 Received: by wye20 with SMTP id 20so4106833wye.20 for ; Sat, 02 Apr 2011 00:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.182.135 with SMTP id cc7mr5114593wbb.91.1301730980271; Sat, 02 Apr 2011 00:56:20 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Sat, 2 Apr 2011 00:56:20 -0700 (PDT) In-Reply-To: <4D95FC41.5060003@redhat.com> References: <4D92103E.90100@redhat.com> <4D933A2E.9030105@redhat.com> <4D949416.5000307@redhat.com> <4D95FC41.5060003@redhat.com> Date: Sat, 02 Apr 2011 07:56:00 -0000 Message-ID: Subject: Re: [cxx-mem-model] bitfield tests From: Richard Guenther To: Richard Henderson Cc: Jeff Law , Aldy Hernandez , gcc-patches , Jakub Jelinek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00113.txt.bz2 On Fri, Apr 1, 2011 at 6:24 PM, Richard Henderson wrote: > On 03/31/2011 08:28 AM, Richard Guenther wrote: >>>> Well, I'm not sure that strict-align targets that provide byte access = do >>>> not simply hide the issue inside the CPU (thus, perform the read-modif= y-write >>>> there and do not guarantee any atomicity unless you ask for it). >>> Certainly some do this internally, but that's clearly out of our >>> control. >> >> Sure. =A0My argument is that the memory model which guarantees >> this kind of things for _any_ memory access is fundamentally flawed. >> They should have simply required annotating objects which should >> behave that way (and then only behave that way "per object", not >> for any concurrent field accesses). > > (0) Let's limit our discussion to cpus that are actually put into SMP sys= tems, > =A0 =A0and have been manufactured in the last decade. > > (1) Do we agree that all such cpus have user-level store insns with byte > =A0 =A0granularity. =A0Honestly the only non-microcontroler I ever heard = of > =A0 =A0without this was the original Alpha. =A0Which is excluded per (0). > > (2) Do we agree that all such cpus have on-chip caches? > > (3) Let us at this point limit our discussion to cacheable, i.e. non-I/O, > =A0 =A0memory. =A0I believe we can agree that all sorts of system-depende= nt stuff > =A0 =A0happens in memory-mapped registers. > > (4) Do we agree that all such cpus transfer entire cachelines to and fro > =A0 =A0the memory bus? =A0And further that they simultaneously transfer a > =A0 =A0modification mask as part of their cache coherency protocol? > > (5) Do we agree that all such cpus use a byte-granular modification mask? > > I'm guessing that you don't actually agree on point (5), but ... honestly, > please name the offender because I can't think of one. =A0For the mainstr= eam > processors we really care about, I think every one of them Does The Right= Thing. Yes, we don't agree on (5). And I can't name a CPU, but I was just guessing that strict alignment CPUs would have such requirement to also make their store queues simpler (no need for such mask). Now, as of (0) I might agree to disregard the original Alpha, but as the embedded world moves to SMP I'm not sure we can disregard non-cache coherent NUMA setups or even CPUs without a byte store. But well, I guess the thing I don't like about the standard is that it makes people that have started to be somewhat aware about threading issues _less_ aware of them by providing some "false" safety to them. It really smells like a standard designed for a very high-level language where people don't have to think instead of a standard suitable for a C family language. Richard. > > > r~ >