This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/59767] New: __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
- From: "mikulas at artax dot karlin.mff.cuni.cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 11 Jan 2014 02:09:04 +0000
- Subject: [Bug target/59767] New: __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
Bug ID: 59767
Summary: __atomic_load_n with __ATOMIC_SEQ_CST should result in
a memory barrier
Product: gcc
Version: 4.8.2
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
The following function:
int f(void)
{
int x;
return __atomic_load_n(&x, __ATOMIC_SEQ_CST);
}
results in this code when compiled with -O2:
f:
.LFB0:
.cfi_startproc
movl -4(%rsp), %eax
ret
.cfi_endproc
.LFE0:
The flag "__ATOMIC_SEQ_CST" should imply a full memory barrier before and after
the operation, but there is no barrier in the generated code.
The bug also exists in 32-bit mode and in x32 mode.
You should place a "mfence" instruction before the movl instruction that loads
the value.
I believe that it is not necessary to place the mfence instruction after the
memory load, but you should better check the ia32 specification for that.