[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