[Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[Bug bootstrap/112534] New: [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534

            Bug ID: 112534
           Summary: [14 regression] build failure after
                    r14-5424-gdb50aea6259545 using gcc 4.8.5
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:db50aea62595452db12565186cb520728540d987, r14-5424-gdb50aea6259545 

We have one old system where gcc fails to build starting with this revision. 
Note even a non-bootstrap build fails.


gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 


make[6]: Entering directory
`/home/seurer/gcc/git/build/gcc-test/gettext/gnulib-lib'
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I.
-I/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib -I.. 
-I../intl -I/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/intl
-DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1   -Wno-cast-qual -Wno-conversion
-Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function
-Wno-unused-parameter -Wno-pedantic -Wno-sign-conversion -Wno-type-limits
-Wno-unsuffixed-float-constants -g -O2     -c -o
malloc/libgrt_a-scratch_buffer_grow.o `test -f 'malloc/scratch_buffer_grow.c'
|| echo
'/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/'`malloc/scratch_buffer_grow.c
In file included from
/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/scratch_buffer.h:115:0,
                 from
/home/seurer/gcc/git/gcc-test/gettext/gettext-runtime/gnulib-lib/malloc/scratch_buffer_grow.c:23:
./malloc/scratch_buffer.gl.h:70:9: error: unknown type name 'max_align_t'
   union { max_align_t __align; char __c[1024]; } __space;
         ^
make[6]: *** [malloc/libgrt_a-scratch_buffer_grow.o] Error 1
make[6]: Leaving directory
`/home/seurer/gcc/git/build/gcc-test/gettext/gnulib-lib'




commit db50aea62595452db12565186cb520728540d987 (HEAD)
Author: Arsen  <C4><87> <arsen@aarsen.me>
Date:   Fri May 19 21:12:57 2023 +0200

    *: add modern gettext

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[pinskia at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[bruno at clisp dot org]

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 ?

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[bruno at clisp dot org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[rguenth at gcc dot gnu.org]

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

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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 ?

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[jakub at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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?

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[jakub at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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?

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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)

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534

--- Comment #11 from seurer at gcc dot gnu.org ---
Did it work?

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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/

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[rguenth at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[arsen at gcc dot gnu.org]

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.

[Bug bootstrap/112534] [14/15 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[rguenth at gcc dot gnu.org]

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.