Hi Prathamesh!
On 2025-01-10T04:17:52+, Prathamesh Kulkarni wrote:
>> -Original Message-
>> From: Thomas Schwinge
>> Sent: 07 January 2025 17:45
>> On 2024-12-20T15:37:42+, Prathamesh Kulkarni
>> wrote:
>> > [...] copying libatomic.a over to $(gcc_objdir)$(MULTISUBDIR)/, and
>
On Fri, Jan 17, 2025 at 12:37:49PM +, Sam James wrote:
> So far, testing has gone well on my end (multilib issues fixed too), but
> I suspect it introduced an issue with RPATH:
libtool install into gcc/$(MULTISUBDIR) isn't a good idea.
Jakub
2025 17:45
>> > To: Prathamesh Kulkarni
>> > Cc: Tobias Burnus ; Joseph Myers
>> > ; Xi Ruoyao ; Matthew
>> > Malcomson ; gcc-patches@gcc.gnu.org; Tom de
>> > Vries
>> > Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>> &g
On Thu, 16 Jan 2025, Prathamesh Kulkarni wrote:
> Hi Joseph,
> Does the above patch in:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673155.html look OK to
> commit (altho it's stage-4 now) ?
> It fixes all the fallouts observed so far (multilib, nvptx offloading,
> libdruntime).
M
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 10 January 2025 09:48
> To: Thomas Schwinge
> Cc: Tobias Burnus ; Joseph Myers
> ; Xi Ruoyao ; Matthew
> Malcomson ; gcc-patches@gcc.gnu.org; Tom de
> Vries
> Subject: RE: [RFC] PR81358: Enable aut
Hi Prathamesh!
Thanks for working on this!
Per my understanding, this patch won't automagically resolve the need to
(occasionally) having to specify '-foffload-options=nvptx-none=-latomic'
for nvptx offloading: it doesn't use 'LINK_LIBATOMIC_SPEC', currently
only used via 'GNU_USER_TARGET_LINK_G
> -Original Message-
> From: Joseph Myers
> Sent: 03 January 2025 22:22
> To: Prathamesh Kulkarni
> Cc: Tobias Burnus ; Xi Ruoyao
> ; Matthew Malcomson ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
&g
On Fri, 20 Dec 2024, Prathamesh Kulkarni wrote:
> Hi,
> The previous patch (now reverted) had two different issues both stemming from
> the rule added in libatomic/Makefile.am:
> (1) As mentioned above, it broke multilib builds because it incorrectly
> copies libatomic.a in $(gcc_objdir). The at
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 20 December 2024 21:08
> To: Prathamesh Kulkarni ; Tobias Burnus
> ; Joseph Myers
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automa
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 18 December 2024 21:09
> To: Tobias Burnus ; Joseph Myers
>
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
&g
> -Original Message-
> From: Tobias Burnus
> Sent: 18 December 2024 17:46
> To: Prathamesh Kulkarni ; Joseph Myers
>
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] PR81358: Enable automatic linking of libatomic
>
&g
On Wed, Dec 18, 2024 at 01:31:15PM +0100, Tobias Burnus wrote:
> I now tried it again – with a patch-wise clean bootstrap and w/o
> --enable-offload-targets=...
> (i.e. on x86_64-gnu-linux with--enable-languages=c,c++,fortran,lto,objc,
> which enables bootstrap + m32 mulilib support).
>
> I think
I now tried it again – with a patch-wise clean bootstrap and w/o
--enable-offload-targets=...
(i.e. on x86_64-gnu-linux with--enable-languages=c,c++,fortran,lto,objc, which enables bootstrap + m32
mulilib support).
I think I saw the same error previously but when trying to see the error again,
A x86_64-gnu-linux bootstrap which also builds -m32 now fails.
While I have local patches, they should not affect this,
hence, I fear that it has been caused by this patch.
Namely, if I do a bootstrap into an empty directory with:
$ /configure --prefix=...
--enable-languages=c,c++,fortra
> -Original Message-
> From: Joseph Myers
> Sent: 04 December 2024 22:19
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: U
On Wed, 4 Dec 2024, Prathamesh Kulkarni wrote:
> Hi Joseph,
> Updated the assert together with setting of CFLAGS in attached patch.
> Bootstrapped+tested on aarch64-linux-gnu (so far).
> Does it look OK ?
This version is OK.
--
Joseph S. Myers
josmy...@redhat.com
> -Original Message-
> From: Joseph Myers
> Sent: 03 December 2024 03:34
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: U
On Mon, 2 Dec 2024, Prathamesh Kulkarni wrote:
> Thanks for the suggestions! Unfortunately, it seems to me that AC_PROG_CC
> also does run tests that
> need modified CFLAGS. I tried the following assertion before invoking
> AC_PROG_CC (for stage-1 build):
>
> if test -z "${CFLAGS}"; then
> AC
> -Original Message-
> From: Joseph Myers
> Sent: 29 November 2024 21:48
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: U
On Fri, 29 Nov 2024, Prathamesh Kulkarni wrote:
> > My expectation is that CFLAGS should not be modified until after
> > save_CFLAGS is set, which should not be until after configure has
> > executed the logic that sets a -g -O2 default. Is there some problem
> > with that ordering (e.g. configur
> -Original Message-
> From: Joseph Myers
> Sent: 28 November 2024 05:45
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: U
On Tue, 19 Nov 2024, Prathamesh Kulkarni wrote:
> +#ifdef USE_LD_AS_NEEDED
> +#define LINK_LIBATOMIC_SPEC "%{!fno-link-libatomic:" LD_AS_NEEDED_OPTION \
> + " -latomic " LD_NO_AS_NEEDED_OPTION "} "
> +#else
> +#define LINK_LIBATOMIC_SPEC ""
> +#endif
I'd expect conditional
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 19 November 2024 22:46
> To: Xi Ruoyao ; josmy...@redhat.com; Matthew
> Malcomson ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use
> -Original Message-
> From: Xi Ruoyao
> Sent: 16 November 2024 09:23
> To: Prathamesh Kulkarni ; josmy...@redhat.com;
> Matthew Malcomson ; gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use
On Sat, 2024-11-16 at 03:44 +, Prathamesh Kulkarni wrote:
> diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in
> index 9798e7c09e9..62cd5e0a76b 100644
> --- a/libatomic/Makefile.in
> +++ b/libatomic/Makefile.in
> @@ -1,7 +1,7 @@
> -# Makefile.in generated by automake 1.15.1 from Makefil
Hi,
The attached patch attempts to enable automatic linking of libatomic, and makes
the following changes:
(1) Introduces a new driver option -f[no]-link-libatomic, which is enabled by
default.
(2) Adds new dependencies in toplevel Makefile.def so libatomic is built before
other target libraries
26 matches
Mail list logo
