> -----Original Message-----
> From: Prathamesh Kulkarni <[email protected]>
> Sent: 29 September 2025 15:28
> To: Sam James <[email protected]>
> Cc: Matthew Malcomson <[email protected]>; gcc-
> [email protected]; Joseph Myers <[email protected]>; Thomas
> Schwinge <[email protected]>
> Subject: RE: [v2] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening links or attachments
>
>
> > -----Original Message-----
> > From: Sam James <[email protected]>
> > Sent: 25 September 2025 18:59
> > To: Prathamesh Kulkarni <[email protected]>
> > Cc: Matthew Malcomson <[email protected]>; gcc-
> > [email protected]; Joseph Myers <[email protected]>; Thomas
> > Schwinge <[email protected]>
> > Subject: Re: [v2] PR81358: Enable automatic linking of libatomic
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Prathamesh Kulkarni <[email protected]> writes:
> >
> > >> -----Original Message-----
> > >> From: Prathamesh Kulkarni <[email protected]>
> > >> Sent: 18 August 2025 16:18
> > >> To: Prathamesh Kulkarni <[email protected]>; Matthew
> Malcomson
> > >> <[email protected]>; [email protected]
> > >> Cc: Joseph Myers <[email protected]>; Thomas Schwinge
> > >> <[email protected]>; Sam James <[email protected]>
> > >> Subject: RE: [v2] PR81358: Enable automatic linking of libatomic
> > >>
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Prathamesh Kulkarni <[email protected]>
> > >> > Sent: 10 August 2025 20:04
> > >> > To: Matthew Malcomson <[email protected]>; gcc-
> > >> [email protected]
> > >> > Cc: Joseph Myers <[email protected]>; Thomas Schwinge
> > >> > <[email protected]>; Sam James <[email protected]>
> > >> > Subject: RE: [v2] PR81358: Enable automatic linking of
> libatomic
> > >> >
> > >> > External email: Use caution opening links or attachments
> > >> >
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Matthew Malcomson <[email protected]>
> > >> > > Sent: 01 August 2025 16:20
> > >> > > To: Prathamesh Kulkarni <[email protected]>; gcc-
> > >> > > [email protected]
> > >> > > Cc: Joseph Myers <[email protected]>; Thomas Schwinge
> > >> > > <[email protected]>; Sam James <[email protected]>
> > >> > > Subject: Re: [v2] PR81358: Enable automatic linking of
> > libatomic
> > >> > >
> > >> > > Hi Prathamesh,
> > >> > >
> > >> > > I've been building on top of this patch and noticed something
> > >> > strange.
> > >> > > In an `arm-none-linux-gnueabihf` build the libatomic
> configure
> > >> > script
> > >> > > no longer recognises that ifunc's are available. Similar
> > happens
> > >> > for
> > >> > > an
> > >> > > x86_64 bootstrap.
> > >> > >
> > >> > > I believe I've tracked it down to the `case` statement just
> > below
> > >> > the
> > >> > > comment that says:
> > >> > > ```
> > >> > > # Check to see if -pthread or -lpthread is needed. Prefer
> the
> > >> > former.
> > >> > > # In case the pthread.h system header is not found, this test
> > >> > > will fail.
> > >> > > ```
> > >> > >
> > >> > > In that case statement there is an unconditional
> > >> > `CFLAGS="$save_CFLAGS
> > >> > > $XPCFLAGS"`.
> > >> > >
> > >> > > In trying to understand why AArch64 didn't have the same
> > problem
> > >> > > I found something else that is slightly worrying -- in the
> use
> > of
> > >> > > `ACX_PROG_CC_WARNING_OPTS` to check whether the AArch64
> target
> > >> > > supports LSE the `ACX_PROG_CC_WARNING_OPTS` macro itself uses
> > >> > > `save_CFLAGS` in a "save what CFLAGS was before this macro
> > used"
> > >> > way.
> > >> > > That means that after the use of `ACX_PROG_CC_WARNING_OPTS`
> we
> > >> > > end
> > >> > up
> > >> > > with `-fno-link-libatomic` in `save_CFLAGS` (which is why the
> > >> above
> > >> > > case statement doesn't block the ifunc objects being created
> in
> > >> > > libatomic for AArch64.
> > >> > >
> > >> > > So I think that points to two things:
> > >> > > 1) Maybe we should use a variable name different to
> > save_CFLAGS?
> > >> > > E.g. I see cet_save_CFLAGS elsewhere in the generated
> > >> > `configure`
> > >> > > script, we could have la_autoinclude_save_CFLAGS or the
> > like.
> > >> > > 2) I believe we should change the `case` statement I
> > referenced.
> > >> > > It resets CFLAGS, but we want to maintain -fno-link-
> > libatomic
> > >> > > in that variable (once the save_CFLAGS no longer
> > artificially
> > >> > > has it for some targets).
> > >> > Hi Matthew,
> > >> > Thanks for the suggestions! In the attached patch, I have
> > modified
> > >> > libatomic/configure.ac to use __libatomic_save_CFLAGS__ instead
> > of
> > >> > save_CFLAGS, so it isn't (accidentally) modified by
> > >> > ACX_PROG_CC_WARNING_OPTS.
> > >> >
> > >> > The patch also fixes couple of other issues you pointed out to
> me
> > >> > privately:
> > >> > (1) In Makefile.def, the patch adds following entry:
> > >> > +lang_env_dependencies = { module=libatomic; no_atomic=true; };
> > >> > To avoid the following circular dependency:
> > >> > make[2]: Circular configure-stage1-target-libatomic <- maybe-
> all-
> > >> > stage1-target-libatomic dependency dropped.
> > >> >
> > >> > (2) Moves the FIXME comment to top-level to avoid the following
> > >> error
> > >> > in libatomic/Makefile.am:
> > >> > Makefile.am:176: error: '#' comment at start of rule is
> > unportable.
> > >> >
> > >> > Patch is bootstrapped + tested on x86_64-linux-gnu, and
> aarch64-
> > >> linux-
> > >> > gnu so far.
> > >> > Joseph, does this patch look OK to you ?
> > >> Hi,
> > >> ping: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > >> August/692287.html
> > > Hi,
> > > ping * 2:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692287.html
> >
> > Prathamesh, could you check it in? Joseph approved it on the 2nd.
> > Thanks!
> Hi,
> Sorry for late response, I slacked a bit due to other tasks.
> I have posted comment on PR requesting for wider testing.
> I plan to commit the patch by end of this week, if there are no
> reports of build/test failures.
I have now committed the patch to trunk in:
https://gcc.gnu.org/cgit/gcc/commit/?id=e63cf4b130b86dd7dde1bf499d3d40faca10ea2e
After following validation:
1] Bootstrap+test on aarch64-linux-gnu and ppc64le-redhat-linux with
--enable-languages=c,c++,fortran,d
2] Bootstrap+test on x86_64-pc-linux-gnu with --enable-languages=all and
multilib enabled.
3] Verified GCC builds with patch on arm-eabi toolchain.
4] Verified there are no change in RPATHS for target libraries (libstdc++ in
particular).
5] Verified the patch doesn't introduce new build failures compared to trunk
for config-list.mk builds.
6] Linaro's CI reported (previous iteration of) patch built OK for aarch32:
https://patchwork.sourceware.org/project/gcc/patch/ia1pr12mb903102844c7379bf41277763ce...@ia1pr12mb9031.namprd12.prod.outlook.com/
7] Sam reported the patch built OK on their system.
Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
> >
> > >
> > > Thanks,
> > > Prathamesh
> > >>
> > >> Thanks,
> > >> Prathamesh
> > >> >
> > >> > Signed-off-by: Prathamesh Kulkarni <[email protected]>
> > >> >
> > >> > Thanks,
> > >> > Prathamesh
> > >> > >
> > >> > > Cheers,
> > >> > > MM
> > >> > >
> > >> > > On 7/22/25 06:03, Prathamesh Kulkarni wrote:
> > >> > > >
> > >> > > >
> > >> > > >> -----Original Message-----
> > >> > > >> From: Prathamesh Kulkarni <[email protected]>
> > >> > > >> Sent: 08 July 2025 08:37
> > >> > > >> To: [email protected]
> > >> > > >> Cc: Matthew Malcomson <[email protected]>; Joseph
> Myers
> > >> > > >> <[email protected]>; Thomas Schwinge
> > >> <[email protected]>;
> > >> > > Sam
> > >> > > >> James <[email protected]>
> > >> > > >> Subject: [v2] PR81358: Enable automatic linking of
> libatomic
> > >> > > >>
> > >> > > >> External email: Use caution opening links or attachments
> > >> > > >>
> > >> > > >>
> > >> > > >> Hi,
> > >> > > >> This is v2 of patch originally posted at:
> > >> > > >> https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > >> > January/673811.html
> > >> > > >>
> > >> > > >> IIUC, there were two outstanding issues with the previous
> > >> patch:
> > >> > > >>
> > >> > > >> (1) LINK_LIBATOMIC_SPEC was only handled in config/gnu-
> > user.h
> > >> and
> > >> > > not
> > >> > > >> in all definitions of LINK_GCC_C_SEQUENCE_SPEC that use
> %L.
> > >> > > >> The attached patch uses LINK_LIBATOMIC_SPEC in all
> > definitions
> > >> of
> > >> > > >> LINK_GCC_C_SEQUENCE_SPEC that use %L. I have tested most
> of
> > >> > > >> the affected targets in patch with stage-1 build (make
> > >> > > >> all-gcc),
> > >> but
> > >> > > not
> > >> > > >> sure if that's sufficient.
> > >> > > >> Does it look OK ?
> > >> > > >>
> > >> > > >> (2) $gcc_objdir ($buid/gcc) was getting added to RPATH,
> > which
> > >> > made
> > >> > > it
> > >> > > >> insecure.
> > >> > > >> The issue in previous patch seems to be primarily coming
> > from
> > >> > > copying
> > >> > > >> of libatomic.la into $gcc_objdir with libtool --
> mode=install
> > >> > > >> libatomic.la, which (somehow) ends up adding $gcc_objdir
> to
> > >> RPATH
> > >> > > in
> > >> > > >> libraries that get built after libatomic, thus making it
> > >> > insecure.
> > >> > > >> I verified that removing libatomic.la from $gcc_objdir
> seems
> > >> > > >> to
> > >> > fix
> > >> > > >> the issue, and there is no more difference in RPATH for
> > built
> > >> > > shared
> > >> > > >> libraries with and without patch.
> > >> > > >> (make install still works correctly by copying
> libatomic.la
> > >> into
> > >> > > >> $DESTDIR).
> > >> > > >> However I am not entirely sure if this is the correct
> > approach
> > >> to
> > >> > > >> resolve RPATH issue, and would be grateful for
> suggestions.
> > >> > > >>
> > >> > > >> So far, the patch is bootstrapped and tested on aarch64-
> > linux-
> > >> gnu
> > >> > > and
> > >> > > >> on x86_64-pc-linux-gnu with multilib enabled with --
> enable-
> > >> > > >> languages=all.
> > >> > > > Hi,
> > >> > > > ping: https://gcc.gnu.org/pipermail/gcc-patches/2025-
> > >> > > July/688838.html
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Prathamesh
> > >> > > >>
> > >> > > >> Signed-off-by: Prathamesh Kulkarni
> <[email protected]>
> > >> > > >>
> > >> > > >> Thanks,
> > >> > > >> Prathamesh
