https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83285

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|missed-optimization         |wrong-code
             Target|x86_64-*-*, i?86-*-*,       |aarch64-linux-gnu
                   |aarch64-*-*                 |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-12-05
     Ever confirmed|0                           |1
           Severity|normal                      |major

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So this is how the RTL for the atomic store for aarch64:

;; __atomic_store_4 (_6, 2, 5);

(insn 9 8 0 (set (mem/v:SI (reg/v/f:DI 75 [ sync ]) [-1  S4 A32])
        (unspec_volatile:SI [
                (const_int 2 [0x2])
                (const_int 5 [0x5])
            ] UNSPECV_STL))
"/data1/src/gcc-cavium/toolchain-7/thunderx-tools/aarch64-thunderx-elf/include/c++/7.2.0/bits/atomic_base.h":374
-1
     (nil))


For x86:

(insn 9 8 10 (set (mem/v:SI (reg/v/f:DI 89 [ sync ]) [-1  S4 A32])
        (unspec:SI [
                (reg:SI 90)
                (const_int 5 [0x5])
            ] UNSPEC_STA))
"/data1/src/gcc-cavium/toolchain-7/tools/include/c++/7.1.0/bits/atomic_base.h":374
-1
     (nil))

(insn 10 9 0 (set (mem/v:BLK (scratch:DI) [0  A8])
        (unspec:BLK [
                (mem/v:BLK (scratch:DI) [0  A8])
            ] UNSPEC_MFENCE))
"/data1/src/gcc-cavium/toolchain-7/tools/include/c++/7.1.0/bits/atomic_base.h":374
-1
     (nil))


This is a bug in aarch64.

See https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync :
"Although x and y are unrelated variables, the memory model specifies that the
assert cannot fail. The store to 'y' happens-before the store to x in thread 1.
If the load of 'x' in thread 2 gets the results of the store that happened in
thread 1, it must all see all operations that happened before the store in
thread 1, even unrelated ones. That means the optimizer is not free to reorder
the two stores in thread 1 since thread 2 must see the store to Y as well."

Reply via email to