From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112375 invoked by alias); 28 Mar 2016 12:12:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 112299 invoked by uid 89); 28 Mar 2016 12:12:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=acquisition, H*Ad:U*andrew, H*r:esmtps, haley X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (46.237.207.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 28 Mar 2016 12:12:09 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1akW1W-0003kA-61; Mon, 28 Mar 2016 14:11:58 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84) (envelope-from ) id 1akW1W-0008I4-29; Mon, 28 Mar 2016 14:11:58 +0200 From: Florian Weimer To: Andrew Haley Cc: Michael Clark , gcc@gcc.gnu.org, cfe-dev@lists.llvm.org, Andrew Waterman , RISC-V Software Developers Subject: Re: Spurious register spill with volatile function argument References: <2600D96D-94BC-4259-9D39-DE4993859281@mac.com> <9F3C9DE6-F00B-4402-A83B-354455DEAFFA@mac.com> <238543C3-39EA-4D5D-8C54-631BF796A38B@mac.com> <56F8F66D.6020002@redhat.com> Date: Mon, 28 Mar 2016 12:12:00 -0000 In-Reply-To: <56F8F66D.6020002@redhat.com> (Andrew Haley's message of "Mon, 28 Mar 2016 10:16:29 +0100") Message-ID: <87egaurecx.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00231.txt.bz2 * Andrew Haley: > "volatile" doesn't really mean very much, formally speaking. Sure, the > standard says "accesses to volatile objects are evaluated > strictly according to the rules of the abstract machine," but nowhere > is it specified exactly what constitutes an access. Reading or modifying an object is defined as =E2=80=9Caccess=E2=80=9D. The problem is that =E2=80=9Creading=E2=80=9D is either not defined, or the= existing flatly contradicts existing practice. For example, if p is a pointer to a struct, will the expression &p->m read *p? Previously, this wasn't very interesting. But under the model memory, it's suddenly quite relevant. If reading p->m implies a read of the entire object *p, you cannot use a member to synchronize access to other members of the struct. For example, if m is a mutex, and carefully acquire the mutex before you read or write other members, you still have data race between a write to some other member and the acquisition of the mutex because the mutex acquisition reads the entire struct (including the member written to ). One possible cure is to take the address of the mutex and keep track of it separately. Or you could construct a pointer using offsetof. But no one is doing that, obviously. This is not entirely hypothetical. Even today, GCC's aliasing analysis requires that those implicit whole-object reads take place, to make certain forms of type-punning invalid which would otherwise be well-defined (and for which GCC would generate invalid code).