[Bug c/54006] New: __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
hp at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Jul 17 22:42:00 GMT 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006
Bug #: 54006
Summary: __atomic_always_lock_free inconsistent with
__GCC_ATOMIC_INT_LOCK_FREE et al.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: hp@gcc.gnu.org
CC: amacleod@redhat.com
Created attachment 27820
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27820
Testcase suitable for gcc.dg/torture
Also affecting C++ and libstdc++.
The definition of the macros in the __GCC_ATOMIC_CHAR_LOCK_FREE,
__GCC_ATOMIC_INT_LOCK_FREE family is inconsistent with
__atomic_always_lock_free.
The latter implies that library calls are always lock-free while the macros
just check for presence of certain patterns. They should call a common
function.
See attached test-case, which fails for crisv32-axis-linux-gnu and "crisv32-elf
-munaligned-atomic-may-use-library" and likely for e.g. m68k coldfire and
definitely for hppa*-* (only library, no patterns).
More information about the Gcc-bugs
mailing list