https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69130
Bug ID: 69130
Summary: explicit atomic ops treating non-constant memory
orders as memory_order_seq_cst
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I hesitated before raising this issue since what GCC does isn't strictly
speaking incorrect. But after thinking about it for a bit I convinced myself it
is a bug (or at least an opportunity for an improvement).
GCC seems to treat invocations of the atomic_xxx_explicit() intrinsics with a
memory order argument that's not a constant expression as if they were to the
sequentially consistent atomic_xxx() built-ins. This shouldn't be a problem
for the correctness of the code, but it does mean that the code will be less
efficient than it could be. The test case below illustrates a couple of basic
instances of the problem.
In contrast, while its code could stand to be improved, Clang checks the memory
order and emits a fence only in the branch that requires it.
$ cat z.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-Wextra -Wpedantic -o/dev/stdout z.c
#include <stdatomic.h>
void store_explicit (_Atomic int *i, memory_order mo)
{
atomic_store_explicit (i, 0, mo);
}
void store (_Atomic int *i, _Bool relax)
{
memory_order mo = relax ? memory_order_relaxed : memory_order_seq_cst;
atomic_store_explicit (i, 0, mo);
}
.file "z.c"
.machine power8
.abiversion 2
.section ".toc","aw"
.section ".text"
.align 2
.p2align 4,,15
.globl store_explicit
.type store_explicit, @function
store_explicit:
sync
li 9,0
stw 9,0(3)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size store_explicit,.-store_explicit
.align 2
.p2align 4,,15
.globl store
.type store, @function
store:
sync
li 9,0
stw 9,0(3)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size store,.-store
.ident "GCC: (GNU) 6.0.0 20151217 (experimental)"
.section .note.GNU-stack,"",@progbits
