[PATCH 0/2] sparc32: restore baseline-V8 glibc builds that need an out-of-line compare-and-swap

[Magnus Lindholm]

Hi Florian,

On Thu, Sep 24, 2026 at 11:10 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Magnus Lindholm:
>
> > The SPARC V8 baseline has no compare-and-swap instruction.  GCC lowers
> > __atomic_compare_exchange and the read-modify-write builtins it cannot
> > inline to calls into libatomic.  glibc cannot link against libatomic,
> > which is itself built against glibc, so any of glibc's own code the
> > compiler happens to lower this way has been unbuildable for this
> > target since libatomic became the compiler's only fallback in 2019.
>
> Shouldn't this be fixed in GCC?  If kernel assists are transparent to
> userspace (and are address-independent etc.), GCC should report these
> atomics as lock-free, and put hte out-of-line implementations into
> libgcc instead of libatomic.
>
> Thanks,
> Florian
>

Fair question, and there's real precedent for it: ARM carried its own
internal kernel-assisted CAS (__kuser_cmpxchg) for pre-ARMv6 hardware for
about two decades, entirely inside glibc, before GCC's own codegen took
it over directly in 2021 (commit f9646d1, BZ #24774) and glibc dropped
its copy for good.

The difference here is that ARM's kernel helper has been an unconditional
part of the ABI since ARM Linux's first release, present on every kernel
a binary could run on, so GCC can just always inline the call, no runtime
check needed. The sparc32 trap doesn't have that history: it's posted

https://lore.kernel.org/sparclinux/20260923201830.865553-1-linmag7@gmail.com/

but not landed, and its ABI details, the memory-ordering contract in
particular, are still moving during review. That's not about a legacy
install base to stay compatible with,  sparc32 doesn't boot mainline at
all yet without the other prerequisite series, it's that until the trap
is actually upstream and stable as part of the ABI, its presence is a
runtime fact glibc has to check via AT_HWCAP, not something GCC can fold
into a compile-time lock-free guarantee the way it could for ARM's
always-present helper.

If that kernel series ends up designed so the trap is unconditionally
safe to call, the kernel choosing internally whether to satisfy it via
real casa or software emulation, the way ARM's kuser page does, then I
agree the ARM path becomes available here too. If anything I'd expect
that to be the natural order: ARM's own mechanism lived as a glibc-
internal stopgap for about two decades before GCC could safely absorb it
in 2021, and a compiler can hardly bake in support for a mechanism
nothing has used yet. I'd rather not gate glibc's ability to build for
this target on that kernel design settling and landing first, but it's
the right longer-term target and this series doesn't foreclose it.

Thanks,
Magnus