> -----Original Message-----
> From: Prathamesh Kulkarni <prathame...@nvidia.com>
> Sent: 10 August 2025 20:04
> To: Matthew Malcomson <mmalcom...@nvidia.com>; gcc-patches@gcc.gnu.org
> Cc: Joseph Myers <josmy...@redhat.com>; Thomas Schwinge
> <tschwi...@baylibre.com>; Sam James <s...@gentoo.org>
> Subject: RE: [v2] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening links or attachments
>
>
> > -----Original Message-----
> > From: Matthew Malcomson <mmalcom...@nvidia.com>
> > Sent: 01 August 2025 16:20
> > To: Prathamesh Kulkarni <prathame...@nvidia.com>; gcc-
> > patc...@gcc.gnu.org
> > Cc: Joseph Myers <josmy...@redhat.com>; Thomas Schwinge
> > <tschwi...@baylibre.com>; Sam James <s...@gentoo.org>
> > 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
Thanks,
Prathamesh
>
> Signed-off-by: Prathamesh Kulkarni <prathame...@nvidia.com>
>
> Thanks,
> Prathamesh
> >
> > Cheers,
> > MM
> >
> > On 7/22/25 06:03, Prathamesh Kulkarni wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Prathamesh Kulkarni <prathame...@nvidia.com>
> > >> Sent: 08 July 2025 08:37
> > >> To: gcc-patches@gcc.gnu.org
> > >> Cc: Matthew Malcomson <mmalcom...@nvidia.com>; Joseph Myers
> > >> <josmy...@redhat.com>; Thomas Schwinge <tschwi...@baylibre.com>;
> > Sam
> > >> James <s...@gentoo.org>
> > >> 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 <prathame...@nvidia.com>
> > >>
> > >> Thanks,
> > >> Prathamesh
