From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64849 invoked by alias); 26 Feb 2017 20:35:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 64839 invoked by uid 89); 26 Feb 2017 20:35:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=resides, facto, states X-HELO: mx1.redhat.com Message-ID: <1488141343.20203.497.camel@redhat.com> Subject: Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros. From: Torvald Riegel To: Florian Weimer Cc: Stefan Liebler , libc-alpha@sourceware.org Date: Sun, 26 Feb 2017 20:35:00 -0000 In-Reply-To: <87bmtosnkf.fsf@mid.deneb.enyo.de> References: <1481905917-15654-1-git-send-email-stli@linux.vnet.ibm.com> <5857CF10.1060100@arm.com> <628f6311-239c-5eea-572c-c2acae6fcbee@linux.vnet.ibm.com> <1487017743.16322.80.camel@redhat.com> <60a34645-17e4-6693-1343-03c55b0c47ad@linux.vnet.ibm.com> <1487437038.20203.68.camel@redhat.com> <8737faedu8.fsf@mid.deneb.enyo.de> <1487596296.20203.119.camel@redhat.com> <87r32ltmh3.fsf@mid.deneb.enyo.de> <1488139553.20203.494.camel@redhat.com> <87bmtosnkf.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-02/txt/msg00503.txt.bz2 On Sun, 2017-02-26 at 21:29 +0100, Florian Weimer wrote: > * Torvald Riegel: > > >> … like this, it would change the C++ name mangling of anything related > >> to pthread_spinlock_t. It is defined as a typedef, so the mangling > >> uses the definition to refer to the type, not the name, according to > >> the language rules, where typedef does not create a new type, and > >> typedefs with the same definition can be used interchangeably. > > > > I'm not saying that we should change the definition to a union. What > > 2.14.2 in the document cited above states is that the pointers to the > > union and the individual parts are interchangeable. So we can use a > > pointer to a part (ie, non-volatile) interchangeably with the pointer to > > the union that we use internally. > > The relevant quote from that document (C memory object and value > semantics: the space of de facto and ISO standards) is: > > | The standard says: 6.7.2.1p16 “The size of a union is > | sufficient to contain the largest of its members. The value of > | at most one of the members can be stored in a union object > | at any time. *A pointer to a union object, suitably converted,* > | *points to each of its members (or if a member is a bit-field,* > | *then to the unit in which it resides), and vice versa.*” (bold > | emphasis added). > > So I think this is only valid if you actually start with a union > object. A plain top-level definition of a volatile int is not a union > member, so this rule does not apply (in the “vice versa” part). Then we'll have to agree to disagree. What do others think about this question? > I think it would be much simpler to ask for a GCC extension which > would allow us to use non-volatile access on a volatile object in a > well-defined fashion. I guess such an "extension" could simply be GCC promising that casts between volatile-qualified T and non-volatile-qualified T are okay if the object is only accessed using one of the two.