From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9358 invoked by alias); 22 Nov 2013 00:20:38 -0000 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 Received: (qmail 9339 invoked by uid 89); 22 Nov 2013 00:20:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Nov 2013 00:20:36 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VjeTi-0001sh-B1 from joseph_myers@mentor.com ; Thu, 21 Nov 2013 16:20:10 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Nov 2013 16:20:10 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Fri, 22 Nov 2013 00:20:08 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VjeTf-0007t2-89; Fri, 22 Nov 2013 00:20:07 +0000 Date: Fri, 22 Nov 2013 03:32:00 -0000 From: "Joseph S. Myers" To: Hans-Peter Nilsson CC: Andrew MacLeod , Subject: Re: Implement C11 _Atomic In-Reply-To: Message-ID: References: <528E1C0A.7020907@redhat.com> <528E2CB6.7020104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-11/txt/msg02802.txt.bz2 On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote: > Oh right, gcc still doesn't remove target-introduced "manual" > alignment checks (when expanding atomic intrinsics), but at > least gcc makes sure it's aligned on stack, when options doesn't > say it's aligned. And a.c:plugh2 doesn't seem to perform an > atomic assignment, but just assignment through an > _Atomic-aligned stack temporary. Might be my C11-ignorance > showing. It appears to me on x86_64 to produce an __atomic_store_4 to *x (in the GIMPLE dumps, what happens after that is a matter for the back end). Note that atomic variable initialization is *not* atomic (see 7.17.2.1 - in general ATOMIC_VAR_INIT needs using with the initializer, or the initialization needs to be carried out with atomic_init, though GCC doesn't require that). (In C11, the effect of a plain initialization without ATOMIC_VAR_INIT is I think that the initializer is evaluated for its side effects, but if the variable gets used as either rvalue or lvalue without one of the special forms of initialization being used first then the behavior is undefined. The idea is to support implementations with extra bits in atomic objects used for locking purposes.) So no atomic store to y is expected - although there are atomic loads from y. -- Joseph S. Myers joseph@codesourcery.com