This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/56414] New: C++11 atomic are not always atomic on load and store depending on the command line on x86-64


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]