From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8D2FD3858C62; Fri, 1 Dec 2023 13:46:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D2FD3858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701438410; bh=322dlhCcf6KujpmemaRs7xvFlGaWiFqXqOsNcL6fgHU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VWThgbv5W4bCiAoBbU8JDOfDmbCPNjexIepeoExwLdpT41OfefzBLVxeRvYKES6CY LSuBN+IUcLvlzcdfyBUTAd/tQNkYjJMJh7NtbLFOTj8COGqEEmYIV3/xZlJC6fVFzo BTCJqreZlQC4ZF8J2ZwAgEh7VpgATD/t5Wy823Vs= From: "jakub 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: Fri, 01 Dec 2023 13:46:48 +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: jakub 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: cc 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 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- 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=3Dgnu99 -std=3Dc99 -c99 -AC99 -D_STDC_C99=3D -qlanglvl=3Dextc99, not f= or -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), but = worse is passed as CC=3D"gcc -std=3Dgnu99" in environment down when doing make all i= n the gettext subdir. I think that is something very similar to how CXX=3D"g++ -std=3Dc++11" is b= eing 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 already defaults to gnu17? Anyway, even when CC =3D gcc, I think that is passed do= wn 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 t= hink is a lot of work), one possibility if we know gettext relies on C11 and new= est 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, 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=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.=