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.
