[Bug target/62253] New: gcc incorrectly mixes direct atomic instructions with calls to atomic library

[mikulas at artax dot karlin.mff.cuni.cz]

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

            Bug ID: 62253
           Summary: gcc incorrectly mixes direct atomic instructions with
                    calls to atomic library
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikulas at artax dot karlin.mff.cuni.cz
              Host: x86_64-unknown-linux-gnu
            Target: x86_64-unknown-linux-gnu
             Build: x86_64-unknown-linux-gnu

Created attachment 33390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33390&action=edit
a test case for broken atomicity on 386. Compile with -O3 -m32 -march=i386

The 386 processor lacks some atomic instructions, thus they must be emulated
using calls to a library.

The library is supposed to take a lock (possibly hashed by the address or the
atomic variable), perform the operation non-atomically, and drop the lock.

However, for some atomic operations, gcc still generates atomic instructions,
even on 386 (lock add, lock sub, lock or, lock and, lock xor, lock inc, lock
dec, xchg). The problem is that when these instructions race with the library
implementation, they break atomicity.

For example, to emulate cmpxchg, the library takes the lock, reads the value,
compares the value, writes the new value, drops the lock. If this sequence
races with directly generated "lock add" instruction, atomicity is broken,
because the lock add instruction can be executed between the read and write in
the cmpxchg library implementation.

To maintain atomicity, gcc must for each data type either always use atomic
instructions or always use calls to the library. It must not mix atomic
instructions and library calls.

To see the bug, compile the attached file with -O3 -m32 -march=i386 . You see
that functions test1, test3, test5 generate direct atomic instructions and
functions test2 and test4 generate calls to the library. When these functions
race with each other, atomicity is not guaranteed.