diff options
author | Robert Edmonds <edmonds@debian.org> | 2014-09-18 20:36:42 -0400 |
---|---|---|
committer | Robert Edmonds <edmonds@debian.org> | 2014-09-18 20:36:42 -0400 |
commit | cc0a047384414991009d95ada9e89b9a92aac531 (patch) | |
tree | b9ff77603a5e5d289b7d707315e58f1a0f24761e /protobuf.pc.in | |
parent | 8d5f1e1efb6c1a99aa4997d519767d5865e06e03 (diff) | |
download | protobuf-cc0a047384414991009d95ada9e89b9a92aac531.tar.gz protobuf-cc0a047384414991009d95ada9e89b9a92aac531.tar.bz2 protobuf-cc0a047384414991009d95ada9e89b9a92aac531.zip |
generic atomicops: promote Acquire_Store() and Release_Load() to use SEQ_CST fence
__atomic_store_n() cannot take a memory model argument of
__ATOMIC_ACQUIRE, and __atomic_load_n() cannot take a memory model
argument of __ATOMIC_RELEASE, per the GCC documentation:
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fatomic-Builtins.html
On Clang this generates a -Watomic-memory-ordering warning.
Promote the fences in Acquire_Store() and Release_Load() to the stronger
__ATOMIC_SEQ_CST memory model, which ought to be safe.
Note that there are no actual uses of Acquire_Store() or Release_Load()
in protobuf, though.
This follows the TSAN atomicops implementation, which also uses SEQ_CST
fences for these functions.
(Fixes #25.)
Diffstat (limited to 'protobuf.pc.in')
0 files changed, 0 insertions, 0 deletions