* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
@ 2023-11-14 23:23 ` pinskia at gcc dot gnu.org
2023-11-15 0:57 ` bruno at clisp dot org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-11-14 23:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm. similar issue happen with gdb 5 years ago:
https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html
Looks like this is huge gnulib mess at that.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
2023-11-14 23:23 ` [Bug bootstrap/112534] " pinskia at gcc dot gnu.org
@ 2023-11-15 0:57 ` bruno at clisp dot org
2023-11-15 1:03 ` bruno at clisp dot org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: bruno at clisp dot org @ 2023-11-15 0:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Bruno Haible <bruno at clisp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bruno at clisp dot org
--- Comment #2 from Bruno Haible <bruno at clisp dot org> ---
> gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
> gcc -std=gnu99 ...
> error: unknown type name 'max_align_t'
The type 'max_align_t' exists in C11, but not in C99, as can be seen from these
uses of gcc 4.8.5:
$ cat foo.c
#include <stddef.h>
max_align_t x;
$ gcc -std=c11 -c foo.c
$ gcc -std=gnu11 -c foo.c
$ gcc -std=c99 -c foo.c
foo.c:2:1: error: unknown type name ‘max_align_t’
max_align_t x;
^
$ gcc -std=gnu99 -c foo.c
foo.c:2:1: error: unknown type name ‘max_align_t’
max_align_t x;
^
But this occurs in the build tree of gettext-runtime, and this package uses
AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU Autoconf
since version 2.70).
Maybe some configure file was built with Autoconf 2.69 and older and thus does
not add -std=gnu11 ?
Or some other configure in the build tree has determined CC="gcc -std=gnu99",
and this setting has been propagated into gettext-runtime, overriding the
findings from gettext-runtime/configure ?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
2023-11-14 23:23 ` [Bug bootstrap/112534] " pinskia at gcc dot gnu.org
2023-11-15 0:57 ` bruno at clisp dot org
@ 2023-11-15 1:03 ` bruno at clisp dot org
2023-11-15 11:58 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: bruno at clisp dot org @ 2023-11-15 1:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #3 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Andrew Pinski from comment #1)
> Hmm. similar issue happen with gdb 5 years ago:
> https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html
Thanks; this is helpful. In this thread we have the explanation
https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00158.html, which
could maybe be the root cause of the problem here.
> Looks like this is huge gnulib mess at that.
This comment is not helpful.
1) As shown in the previous comment, max_align_t problems arise from the use of
-std=... options that are too old. We are in the year 2023, and it seems right
to use ISO C 11 features (from a 12 years old standard), no?
2) Gnulib actually works around two problems related to max_align_t, as
documented here:
https://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html
Without Gnulib, you would encounter more problems related to max_align_t, not
fewer.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2023-11-15 1:03 ` bruno at clisp dot org
@ 2023-11-15 11:58 ` rguenth at gcc dot gnu.org
2023-11-15 14:27 ` arsen at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-15 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
Keywords| |build
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2023-11-15 11:58 ` rguenth at gcc dot gnu.org
@ 2023-11-15 14:27 ` arsen at gcc dot gnu.org
2023-12-01 13:46 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2023-11-15 14:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #4 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #2)
> > gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
> > gcc -std=gnu99 ...
> > error: unknown type name 'max_align_t'
>
> The type 'max_align_t' exists in C11, but not in C99, as can be seen from
> these uses of gcc 4.8.5:
> $ cat foo.c
> #include <stddef.h>
> max_align_t x;
> $ gcc -std=c11 -c foo.c
> $ gcc -std=gnu11 -c foo.c
> $ gcc -std=c99 -c foo.c
> foo.c:2:1: error: unknown type name ‘max_align_t’
> max_align_t x;
> ^
> $ gcc -std=gnu99 -c foo.c
> foo.c:2:1: error: unknown type name ‘max_align_t’
> max_align_t x;
> ^
>
> But this occurs in the build tree of gettext-runtime, and this package uses
> AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU
> Autoconf since version 2.70).
>
> Maybe some configure file was built with Autoconf 2.69 and older and thus
> does not add -std=gnu11 ?
The toolchain tree is generated with AC2.69, indeed. The gettext-runtime files
should be unaltered from the release gettext tarball, though.
> Or some other configure in the build tree has determined CC="gcc
> -std=gnu99", and this setting has been propagated into gettext-runtime,
> overriding the findings from gettext-runtime/configure ?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2023-11-15 14:27 ` arsen at gcc dot gnu.org
@ 2023-12-01 13:46 ` jakub at gcc dot gnu.org
2023-12-05 22:21 ` arsen at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-01 13:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that the toplevel configure (which is autoconf 2.69 as pretty
much everything in gcc) uses the older AC_PROG_CC, which only checks for
-std=gnu99 -std=c99 -c99 -AC99 -D_STDC_C99= -qlanglvl=extc99, not for
-std=gnu11.
And sets
CC = @CC@
in toplevel Makefile.in to
CC = gcc -std=gnu99
in toplevel objdir Makefile. That gets then passed to in-tree gettext (if
present, I really don't think you need it on powerpc64-linux-gnu, perhaps
download_prerequisities should be smarter and check if gettext is really
needed) configure (where it just means
CC is set there to gcc -std=gnu99 -std=gnu11 in gettext/Makefile), but worse is
passed as CC="gcc -std=gnu99" in environment down when doing make all in the
gettext subdir.
I think that is something very similar to how CXX="g++ -std=c++11" is being
passed down
to in-tree isl build and breaks with recent isl which wants to use C++17 or
what.
Strangely, in my x86_64-linux toplevel Makefile I only have
CC = gcc
CXX = g++ -std=c++11
Dunno why it hasn't added -std=gnu99 there, maybe because that gcc already
defaults to gnu17? Anyway, even when CC = gcc, I think that is passed down to
make of the in-tree compilations.
So, I guess if we don't want to switch to autoconf 2.70 or later (which I think
is a lot of work), one possibility if we know gettext relies on C11 and newest
ISL relies on C++17 (does it really?) would be to add explicit probing in
configure for -std=gnu11 or -std=c11 and if that works, pass it down in the
gettext build case; and similarly for isl. Maybe better not in CC/CXX but in
CFLAGS/CXXFLAGS?
The propagation of flags is done in $(HOST_EXPORTS) and for stage2+
$(POSTSTAGE1_HOST_EXPORTS).
Looking around in Makefile.def, I see e.g. for gmp/mpfr we use
extra_make_flags='AM_CFLAGS="-DNO_ASM"';
and for isl
extra_make_flags='V=1';
Dunno if it would work to add for the gettext case
extra_make_flags='CFLAGS="$(CFLAGS) @C11_CFLAGS@"';
with configure check for C11_FLAGS or something similar.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2023-12-01 13:46 ` jakub at gcc dot gnu.org
@ 2023-12-05 22:21 ` arsen at gcc dot gnu.org
2023-12-05 22:26 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2023-12-05 22:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #6 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> The problem is that the toplevel configure (which is autoconf 2.69 as pretty
> much everything in gcc) uses the older AC_PROG_CC, which only checks for
> -std=gnu99 -std=c99 -c99 -AC99 -D_STDC_C99= -qlanglvl=extc99, not for
> -std=gnu11.
> And sets
> CC = @CC@
> in toplevel Makefile.in to
> CC = gcc -std=gnu99
> in toplevel objdir Makefile. That gets then passed to in-tree gettext (if
> present, I really don't think you need it on powerpc64-linux-gnu, perhaps
> download_prerequisities should be smarter and check if gettext is really
> needed) configure (where it just means
> CC is set there to gcc -std=gnu99 -std=gnu11 in gettext/Makefile), but worse
> is passed as CC="gcc -std=gnu99" in environment down when doing make all in
> the gettext subdir.
> I think that is something very similar to how CXX="g++ -std=c++11" is being
> passed down
> to in-tree isl build and breaks with recent isl which wants to use C++17 or
> what.
> Strangely, in my x86_64-linux toplevel Makefile I only have
> CC = gcc
> CXX = g++ -std=c++11
> Dunno why it hasn't added -std=gnu99 there, maybe because that gcc already
> defaults to gnu17? Anyway, even when CC = gcc, I think that is passed down
> to make of the in-tree compilations.
> So, I guess if we don't want to switch to autoconf 2.70 or later (which I
> think is a lot of work), one possibility if we know gettext relies on C11
> and newest ISL relies on C++17 (does it really?) would be to add explicit
> probing in configure for -std=gnu11 or -std=c11 and if that works, pass it
> down in the gettext build case; and similarly for isl. Maybe better not in
> CC/CXX but in CFLAGS/CXXFLAGS?
> The propagation of flags is done in $(HOST_EXPORTS) and for stage2+
> $(POSTSTAGE1_HOST_EXPORTS).
>
> Looking around in Makefile.def, I see e.g. for gmp/mpfr we use
> extra_make_flags='AM_CFLAGS="-DNO_ASM"';
> and for isl
> extra_make_flags='V=1';
> Dunno if it would work to add for the gettext case
> extra_make_flags='CFLAGS="$(CFLAGS) @C11_CFLAGS@"';
> with configure check for C11_FLAGS or something similar.
yes, that seems doable but I am curious about why the flag propagation via
export is necessary. would each configure not already have the appropriate
flags set?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2023-12-05 22:21 ` arsen at gcc dot gnu.org
@ 2023-12-05 22:26 ` jakub at gcc dot gnu.org
2023-12-05 22:53 ` arsen at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-05 22:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Arsen Arsenović from comment #6)
> yes, that seems doable but I am curious about why the flag propagation via
> export is necessary. would each configure not already have the appropriate
> flags set?
Exporting say CC or CXX to the host CC/CXX in stage1 and previous-stage/xgcc -B
previous-stage/ and similar is obviously required, otherwise bootstrap wouldn't
work at all. And various config/*.mk amend various other make variables in
various different stages as needed.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2023-12-05 22:26 ` jakub at gcc dot gnu.org
@ 2023-12-05 22:53 ` arsen at gcc dot gnu.org
2023-12-13 17:24 ` arsen at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2023-12-05 22:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #8 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> Exporting say CC or CXX to the host CC/CXX in stage1 and previous-stage/xgcc
> -B previous-stage/ and similar is obviously required, otherwise bootstrap
> wouldn't work at all. And various config/*.mk amend various other make
> variables in various different stages as needed.
sure, but is that necessary in 'all-*' stages if 'configure-*' already had CC
et al exported?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2023-12-05 22:53 ` arsen at gcc dot gnu.org
@ 2023-12-13 17:24 ` arsen at gcc dot gnu.org
2023-12-21 9:05 ` arsen at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2023-12-13 17:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #9 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
removing EXTRA_HOST_FLAGS from the gettext targets fixed the build on my
cfarm112.
overall, I'm not sure overriding what subconfigures discover and adjust CC and
CFLAGS with is a good idea. it seems sensible to allow subpackages to have
that disabled (or to require packages to enable that functionality, but that
change would be more intrusive)
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2023-12-13 17:24 ` arsen at gcc dot gnu.org
@ 2023-12-21 9:05 ` arsen at gcc dot gnu.org
2024-01-03 2:26 ` seurer at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2023-12-21 9:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #10 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
Created attachment 56915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56915&action=edit
[PATCH] toplevel: don't override gettext-runtime/configure-discovered build
args
here's a preliminary patch, currently trying it on cfarm112.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2023-12-21 9:05 ` arsen at gcc dot gnu.org
@ 2024-01-03 2:26 ` seurer at gcc dot gnu.org
2024-01-03 11:27 ` arsen at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: seurer at gcc dot gnu.org @ 2024-01-03 2:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #11 from seurer at gcc dot gnu.org ---
Did it work?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2024-01-03 2:26 ` seurer at gcc dot gnu.org
@ 2024-01-03 11:27 ` arsen at gcc dot gnu.org
2024-03-27 13:38 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2024-01-03 11:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #12 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to seurer from comment #11)
> Did it work?
yes, I sent it on the ML:
https://inbox.sourceware.org/gcc-patches/20231221193243.368541-1-arsen@aarsen.me/
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2024-01-03 11:27 ` arsen at gcc dot gnu.org
@ 2024-03-27 13:38 ` rguenth at gcc dot gnu.org
2024-03-27 18:47 ` arsen at gcc dot gnu.org
2024-05-07 7:42 ` [Bug bootstrap/112534] [14/15 " rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-27 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-03-27
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like the patch is still not reviewed. I haven't had issues with using
system gettext though.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (13 preceding siblings ...)
2024-03-27 13:38 ` rguenth at gcc dot gnu.org
@ 2024-03-27 18:47 ` arsen at gcc dot gnu.org
2024-05-07 7:42 ` [Bug bootstrap/112534] [14/15 " rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: arsen at gcc dot gnu.org @ 2024-03-27 18:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #14 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
indeed, system gettext should be unaffected.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug bootstrap/112534] [14/15 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
2023-11-14 23:14 [Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 seurer at gcc dot gnu.org
` (14 preceding siblings ...)
2024-03-27 18:47 ` arsen at gcc dot gnu.org
@ 2024-05-07 7:42 ` rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.0 |14.2
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
^ permalink raw reply [flat|nested] 17+ messages in thread