[Bug c/59448] Code generation doesn't respect C11 address-dependency
joseph at codesourcery dot com
gcc-bugzilla@gcc.gnu.org
Tue Dec 10 17:47:00 GMT 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The code generated appears fully in accordance with the semantics of C11.
You refer to 5.1.2.4#14, the definition of "carries a dependency". The
term "carries a dependency" is used outside its own definition only in the
definition of "dependency-ordered before". This testcase contains no
instances of "dependency-ordered before", because any such instance must
directly or indirectly involve a case of "A performs a release operation
on an atomic object M, and, in another thread, B performs a consume
operation on M and reads a value written by any side effect in the release
sequence headed by A", and the test involves no atomic objects.
"dependency-ordered before", in turn, is only used in the definition of
"inter-thread happens before", which is only used in the definition of
"happens before".
Please provide a complete testcase, using _Atomic or <stdatomic.h> (and so
using GCC 4.9, of course) that demonstrates any bug: that is, that does
not contain a data race according to the C11 definition, but where GCC has
reordered code in a way that introduces one (and so one can be
demonstrated by enough iterations of the threads in the testcase) - or
where the code generated fails some other semantics associated with
"happens before", such as those for "visible side effect" and "visible
sequence of side effects". I expect any such bug, and fix, would probably
not be a front-end issue but an issue with the atomic built-in functions
failing to ensure appropriate ordering in the presence of dependencies
involving atomic operations (dependencies not involving such operations
having no effects on C11 semantics).
More information about the Gcc-bugs
mailing list