From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29975 invoked by alias); 17 Feb 2014 21:03:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29938 invoked by uid 48); 17 Feb 2014 21:03:03 -0000 From: "torvald at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/59448] Code generation doesn't respect C11 address-dependency Date: Mon, 17 Feb 2014 21:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torvald at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg01739.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #12 from torvald at gcc dot gnu.org --- (In reply to algrant from comment #11) > Where do you get that this is racy if the access to data is not atomic? In threadB(), you do: f = flag.load(std::memory_order_consume); // B.A d = *(&data + f - f); // B.B That reads from data irrespective of the value of f, so will read when data is actually not "owned" by threadB. You can either make the accesses to data atomic, or move the load from data to after checking that flag equals 1. > By > design, release/acquire and release/consume sequences don't require > wholesale changes to the way the data payload (in the general case, multiple > fields within a structure) is first constructed and then used. 1.10#13 > makes clear that as a result of the intra-thread sequencing between atomic > and non-atomic operations (1.9#14), and the inter-thread ordering between > atomic operations (1.10 various), there is a resulting ordering on > operations to "ordinary" (sic) objects. Please see the references to the > C++ standard in the source example, for the chain of reasoning here. I'm very much aware of the rules, I believe. But as far as you can see, there's a data race in your test program, which results in undefined behavior.