This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 20 Jan 2014 14:21:17 +0000
- Subject: [Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
- Auto-submitted: auto-generated
- References: <bug-59448-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Thanks for the testcase. At this point I think we need Andrew MacLeod or
Torvald Riegel to review it and assess what should happen where to fix
this (both for direct uses of the atomic built-in functions, and for
_Atomic / std::atomic).
Since the original bug report it has come to my attention that there are
known ambiguities in how the C11/C++11 memory model is mapped to processor
operations on some architectures, which will need to be addressed in
platform ABIs for interoperation between implementations (when one thread
is built with one implementation and the other thread with another
implementation, for example).
http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
(It is not clear to me if research in this area is sufficiently advanced
to provide a good way for ABIs to specify this that is unambiguous and
does not inhibit optimizations within a single implementation.)
It will also of course be necessary for ABIs to specify such things as
alignment for C11 _Atomic for that to interoperate between implementations
(for GCC at present, if the size of the type is 8 / 16 / 32 / 64/ 128
bits, the alignment gets increased to match that of the corresponding core
type). But first it may take a while for things to work reliably within
single implementations.