http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Dmitry Vyukov <dvyukov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dvyukov at google dot com
--- Comment #9 from Dmitry Vyukov <dvyukov at google dot com> ---
(In reply to Jakub Jelinek from comment #4)
> Because CPUs obviously don't have floating point atomic instructions, what
> the compiler does is just load it as an integer, view convert to floating
> point, perform arithmetics, view convert result back to integer, and compare
> and swap (if unsuccessful loop). I bet tsan complains because the load is
> not atomic, but does it really matter? If we read garbage there, compare
> and swap will fail and next time we'll have hopefully correct value already
> from what compare and swap said was the previous value.
Data races do not work this way. It's undefined behavior:
http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
The code must use relaxed atomic load. If the code becomes slower due to that
then:
(1) the current generated code is incorrect
or (2) there is a performance bug in gcc handling of atomic operations
