public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "filter-gcc at preshing dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
Date: Thu, 30 Oct 2014 22:16:00 -0000 [thread overview]
Message-ID: <bug-59448-4-gPaaetDNE0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59448-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
preshing <filter-gcc at preshing dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |filter-gcc at preshing dot com
--- Comment #22 from preshing <filter-gcc at preshing dot com> ---
(In reply to algrant from comment #13)
> I see what you mean - there is a race if threadB reads the data when the
> flag is not set, i.e. in the case when the read value is never used.
> Moving the read of data after the test (as in the fragment in comment 4)
> would fix the race.
algrant, could you post the complete assembly listing for threadB(), using your
version of AArch64 g++, after all the corrections to the example have been
taken into account, with -O2? For convenience, I've posted the corrected
example below.
When I compile the example using PowerPC g++ 4.9.1, it seems that
memory_order_consume is already promoted to memory_order_acquire, as evidenced
by the cmpw;bne-;isync sequence following the load from flag, which acts as an
acquire barrier. I've posted the PowerPC assembly listing below as well.
Is the bug specific to AArch64?
-------------
/* Reproducer for 59448: compile with -std=c++11 -lpthread -O2 */
#include <atomic>
#include <thread>
#include <stdio.h>
#include <assert.h>
static std::atomic<unsigned int> flag(0);
static int data;
/*
Thread A tries to release a data value 1 to thread B via a
release/consume sequence.
In the demonstration, this is tried repeatedly. The iterations of
the two threads are synchronized via a release/acquire sequence
from B to A. This is not relevant to the ordering problem.
*/
void threadA(void)
{
for (;;) {
data = 1; // A.A
flag.store(1, std::memory_order_release); // A.B
/* By 1.9#14, A.A is sequenced before A.B */
/* Now wait for thread B to accept the data. */
while (flag.load(std::memory_order_acquire) == 1);
assert(data == 0);
}
}
void threadB(void)
{
for (;;) {
int f, d;
do {
f = flag.load(std::memory_order_consume); // B.A
} while (!f);
/* By 1.10#9, B.A carries a dependency to B.B */
/* By 1.10#10, A.B is dependency-ordered before B.B */
/* By 1.10#11, A.A intra-thread happens before B.B */
/* By 1.10#12, A.A happens before B.B */
/* By 1.10#13, A.A is a visible side-effect with respect to B.B
and the value determined by B.B shall be the
value (1) stored by A.A. */
d = *(&data + (f - f)); // B.B
assert(d == 1);
/* Release thread A to start another iteration. */
data = 0;
flag.store(0, std::memory_order_release);
}
}
int main(void)
{
std::thread a(&threadA);
std::thread b(&threadB);
a.join();
b.join();
return 0;
}
------------- PowerPC listing of threadB():
_Z7threadBv:
.LFB2302:
.cfi_startproc
lis 10,.LANCHOR0@ha
li 8,0
la 10,.LANCHOR0@l(10)
.L16:
lwz 9,4(10)
cmpw 7,9,9 <------- acquire barrier
bne- 7,$+4 <-------
isync <-------
cmpwi 7,9,0
beq+ 7,.L16
lwz 9,0(10)
cmpwi 7,9,1
bne- 7,.L22
stw 8,0(10)
lwsync
stw 8,4(10)
b .L16
.L22:
mflr 0
lis 6,.LANCHOR1@ha
stwu 1,-16(1)
.cfi_def_cfa_offset 16
.cfi_register 65, 0
lis 3,.LC2@ha
lis 4,.LC1@ha
la 6,.LANCHOR1@l(6)
la 3,.LC2@l(3)
la 4,.LC1@l(4)
li 5,47
addi 6,6,16
stw 0,20(1)
.cfi_offset 65, 4
bl __assert_fail
.cfi_endproc
next prev parent reply other threads:[~2014-10-30 22:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 12:07 [Bug target/59448] New: ARM code " algrant at acm dot org
2013-12-10 14:19 ` [Bug c/59448] Code " rearnsha at gcc dot gnu.org
2013-12-10 16:43 ` algrant at acm dot org
2013-12-10 17:47 ` joseph at codesourcery dot com
2013-12-12 18:07 ` [Bug middle-end/59448] " algrant at acm dot org
2013-12-16 14:38 ` joseph at codesourcery dot com
2014-01-20 8:52 ` algrant at acm dot org
2014-01-20 9:02 ` pinskia at gcc dot gnu.org
2014-01-20 10:13 ` algrant at acm dot org
2014-01-20 14:21 ` joseph at codesourcery dot com
2014-01-23 22:28 ` torvald at gcc dot gnu.org
2014-02-17 10:26 ` algrant at acm dot org
2014-02-17 21:03 ` torvald at gcc dot gnu.org
2014-02-17 22:22 ` algrant at acm dot org
2014-10-28 10:56 ` ramana at gcc dot gnu.org
2014-10-28 12:48 ` amacleod at redhat dot com
2014-10-28 13:43 ` joseph at codesourcery dot com
2014-10-28 17:37 ` t.p.northover at gmail dot com
2014-10-29 1:48 ` joseph at codesourcery dot com
2014-10-29 9:23 ` torvald at gcc dot gnu.org
2014-10-30 21:08 ` torvald at gcc dot gnu.org
2014-10-30 22:16 ` filter-gcc at preshing dot com [this message]
2014-11-24 12:13 ` filter-gcc at preshing dot com
2015-01-14 13:59 ` amacleod at redhat dot com
2022-01-15 1:47 ` pinskia at gcc dot gnu.org
2022-01-15 1:53 ` pinskia at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-59448-4-gPaaetDNE0@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).