[PATCH] libstdc++: Remove unused config/cpu/i486/atomicity.h file [PR122172]
Jonathan Wakely
jwakely@redhat.com
Tue Oct 7 18:53:16 GMT 2025
On Tue, 7 Oct 2025 at 18:31, Hans-Peter Nilsson <hp@axis.com> wrote:
>
> > From: Jonathan Wakely <jwakely@redhat.com>
> > Date: Tue, 7 Oct 2025 17:32:55 +0100
>
> > On Tue, 7 Oct 2025 at 17:29, Hans-Peter Nilsson <hp@axis.com> wrote:
> > >
> > > > From: Jonathan Wakely <jwakely@redhat.com>
> > >
> > > > This file is no longer used, because we always use the definitions in
> > > > config/cpu/generic/atomicity_builtins/atomicity.h now.
> > > >
> > > > HP confirmed that the code generated by __atomic_fetch_add is fine and
> > > > we don't need the handwritten assembly.
> > >
> > > Right, just please s/i486/CRIS/ in the subject.
> >
> > Doh! I'm also planning to remove config/cpu/i486/atomicity.h which is
> > also unused, and I reused the commit message.
>
> Didn't look like this patch was in a series, so:
> aren't all libstdc++-v3/config/cpu/*/atomicity.h unused?
Not all of them, but maybe more than just i486 and cris, those are
just the ones I've only confirmed so far.
The config/cpu/generic/atomic_builtins/atomicity.h file will only be
used if __atomic_fetch_add on _Atomic_word doesn't need to link to
libatomic, which isn't necessarily true for all of these:
config/cpu/cris/atomicity.h
config/cpu/hppa/atomicity.h
config/cpu/i386/atomicity.h
config/cpu/i486/atomicity.h
config/cpu/m68k/atomicity.h
config/cpu/sh/atomicity.h
config/cpu/sparc/atomicity.h
I don't think we can remove it for i386 or 32-bit sparc because
changing from the current spinlock based __exchange_and_add to using
__atomic_fetch_add would be an ABI break.
It looks like sh needs a libatomic call. I haven't checked the others.
> (To all -other- wise guys: no, * doesn't match "generic" here,
> as there's no libstdc++-v3/config/cpu/generic/atomicity.h)
>
> Not to be confused with
> config/cpu/generic/atomicity_builtins/atomicity.h and
> config/cpu/generic/atomicity_mutex/atomicity.h (or: a
> confusion being cleared up).
Indeed :-)
More information about the Libstdc++
mailing list