From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 176853858D37; Tue, 5 Dec 2023 22:21:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 176853858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701814875; bh=OOfeEmoDT5q9gwzJ+HX8MKneS6q7mtNNxDfgHJHicVo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hNGNVcapuaY/DP7CQpfxDrrrBCLgjxmkY7tZOnXvzCYFkzUI/YhLlmAH4FHbhEO3z MLFEXMVBTt+0NDR1UyaHctvPh0ecucrFsGOUg60evDezrur+gTpJltvt0SMhG9uJ6V drG58KkdrYtxaThcnGts6UBavytsb7J7ForYLYcY= From: "arsen at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5 Date: Tue, 05 Dec 2023 22:21:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: arsen at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112534 --- Comment #6 from Arsen Arsenovi=C4=87 --- (In reply to Jakub Jelinek from comment #5) > The problem is that the toplevel configure (which is autoconf 2.69 as pre= tty > much everything in gcc) uses the older AC_PROG_CC, which only checks for > -std=3Dgnu99 -std=3Dc99 -c99 -AC99 -D_STDC_C99=3D -qlanglvl=3Dextc99, not= for > -std=3Dgnu11. > And sets > CC =3D @CC@ > in toplevel Makefile.in to > CC =3D gcc -std=3Dgnu99 > 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=3Dgnu99 -std=3Dgnu11 in gettext/Makefile), bu= t worse > is passed as CC=3D"gcc -std=3Dgnu99" in environment down when doing make = all in > the gettext subdir. > I think that is something very similar to how CXX=3D"g++ -std=3Dc++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 =3D gcc > CXX =3D g++ -std=3Dc++11 > Dunno why it hasn't added -std=3Dgnu99 there, maybe because that gcc alre= ady > defaults to gnu17? Anyway, even when CC =3D 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=3Dgnu11 or -std=3Dc11 and if that works, pa= ss 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). >=20 > Looking around in Makefile.def, I see e.g. for gmp/mpfr we use > extra_make_flags=3D'AM_CFLAGS=3D"-DNO_ASM"'; > and for isl > extra_make_flags=3D'V=3D1'; > Dunno if it would work to add for the gettext case > extra_make_flags=3D'CFLAGS=3D"$(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?=