This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/56414] New: C++11 atomic are not always atomic on load and store depending on the command line on x86-64
- From: "valentin.david at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 20 Feb 2013 22:07:44 +0000
- Subject: [Bug libstdc++/56414] New: C++11 atomic are not always atomic on load and store depending on the command line on x86-64
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56414
Bug #: 56414
Summary: C++11 atomic are not always atomic on load and store
depending on the command line on x86-64
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: valentin.david@gmail.com
In the standard, in section [1.10.21], it is explained that data races happen
when one of conflicting operations is not atomic. Which means that when they
are all atomic, we should not get any data race. On x86-64, load and stores on
native scalars seem to be atomic operations only if they are not across cache
lines. If I change the alignment of scalars, I can make non atomic scalars.
std::atomic should always be aligned correctly even if the options or
attributes are asking otherwise. For example, if use "-fpack-struct=1", then my
"atomic" fields are not properly aligned anymore.
$ g++ -std=c++0x -pthread -fpack-struct=1
$ ./a.out
72057594037927935
a.out: foo.cc:34: main()::__lambda2: Assertion `v == 0 || v == -1' failed.
Aborted