https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122078

            Bug ID: 122078
           Summary: libatomic is inconsistent with GCC intrinsic
                    __atomic_test_and_set
           Product: gcc
           Version: 14.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fede.tft at miosix dot org
  Target Milestone: ---

GCC defines the __atomic_test_and_set builtin in gcc/sync-builtins.def
libatomic, which from my understanding should provide a fallback implementation
for missing atomic builtins, does not provide an __atomic_test_and_set
function. Instead, the file libatomic/tas_n.c provides four functions:
__atomic_test_and_set_1
__atomic_test_and_set_2
__atomic_test_and_set_4
__atomic_test_and_set_8
(the function generation is somewhat obscured by the file being compiled
multiple times with different values for SIZE and the function names being
hidden by the EXPORT_ALIAS macro).

As a result of this naming mismatch, code using __atomic_test_and_set does not
compile on platforms where GCC does not provide the intrinsic (that is, for
CPUs missing atomic instructions). Moreover, no one seems to use
__atomic_test_and_set_{2,4,8}, or at least a grep in the GCC source code leads
nowhere.

We are observing this issue on the armv6-m architecture after this this bugfix
was introduced:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567
but the problem seems much older and the root cause seems to be a bug in
libatomic: while other intrinsics such as __atomic_compare_exchange do have
different overloads for the object size in both GCC and libatomic, test and set
only makes sense for bool/char, or at least those who did not provide overloads
in the GCC intrinsics think so. Maybe tas_n.c was developed by copy-pasting
another file? I also see no test for __atomic_test_and_set in libatomic's
testsuite.

I'm reporting the bug for GCC 14.2.0 as this is when we first observed it, but
I checked in the git HEAD at https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git and
the problem seems to be still present.

Related bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280

Reply via email to