From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 134ED3858C33; Thu, 29 Sep 2022 10:06:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 134ED3858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664445978; bh=skwvQ5Kd2Ktwjafmzims3KZOFmN6xRJasvHNkXhNsvM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DEi7R+j8+mq5UW+DCoYU9EfdazQdh6Od7jB2HeIYSSw7dvETgjlPDFGLG+nWQmaH4 p5RnrlsiVx+dBDT3w6dWGGUEgHo3PgNHFHxC5M92maQzB3GvUoa7WqF39pwiDwKzxC gN1qdWoUbCzO+NWRl5rX3nPhJu8DyuFRH6zz6690= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34 Date: Thu, 29 Sep 2022 10:06:16 +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: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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=3D107059 --- Comment #28 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a5a9237e2a78a9854f1f87e63ef5619cf8ba7360 commit r13-2932-ga5a9237e2a78a9854f1f87e63ef5619cf8ba7360 Author: Jakub Jelinek Date: Thu Sep 29 12:04:24 2022 +0200 driver, cppdefault: Unbreak bootstrap on Debian/Ubuntu [PR107059] My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++ apparently broke bootstrap on some Debian/Ubuntu setups. Those multiarch targets put some headers into /usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of /usr/include/bits/. This is handled by /* /usr/include comes dead last. */ { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1= , 2 }, { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1= , 0 }, in cppdefault.cc, where the 2 in the last element of the first initiali= zer means the entry is ignored on non-multiarch and suffixed by the multiar= ch dir otherwise, so installed gcc has search path like: =20=20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include =20=20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include (when installed with DESTDIR=3D/home/jakub/gcc/obj01inst). Now, when fixincludes is run, it is processing the whole /usr/include d= ir and all its subdirectories, so floatn{,-common.h} actually go into .../include-fixed/x86_64-linux-gnu/bits/floatn{,-common.h} because that is where they appear in /usr/include too. In some setups, /usr/include also contains /usr/include/bits -> x86_64-linux-gnu/bits symlink and after the r13-2896 tweak it works. In other setups there is no /usr/include/bits symlink and when one #include given the above search path, it doesn't find the fixincluded header, as =20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include-fixed/bits/floatn.h doesn't exist and =20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include-fixed/x86_64-linux-gnu/bits/floatn.h isn't searched and so /usr/include/x86_64-linux-gnu/bits/floatn.h wins and we fail because of typedef whatever _Float128; and similar. The following patch ought to fix this. The first hunk by arranging that the installed search path actually looks like: =20=20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include =20=20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include-fixed/x86_64-linux-gnu =20=20=20=20 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0= .0/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include and thus for include-fixed it treats it the same as /usr/include. The second FIXED_INCLUDE_DIR entry there is: { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, /* A multilib suffix needs adding if different multilibs use different headers. */ #ifdef SYSROOT_HEADERS_SUFFIX_SPEC 1 #else 0 #endif }, where SYSROOT_HEADERS_SUFFIX_SPEC is defined only on vxworks or mips*-mti-linux and arranges for multilib path to be appended there. Neither of those systems is multiarch. This isn't enough, because when using the -B option, the driver adds -isystem .../include-fixed in another place, so the second hunk modifies that spot the same. /home/jakub/gcc/obj01/gcc/xgcc -B /home/jakub/gcc/obj01/gcc/ then has search path: /home/jakub/gcc/obj01/gcc/include /home/jakub/gcc/obj01/gcc/include-fixed/x86_64-linux-gnu /home/jakub/gcc/obj01/gcc/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include which again is what I think we want to achieve. 2022-09-29 Jakub Jelinek PR bootstrap/107059 * cppdefault.cc (cpp_include_defaults): If SYSROOT_HEADERS_SUFFIX_SPEC isn't defined, add FIXED_INCLUDE_DIR entry with multilib flag 2 before FIXED_INCLUDE_DIR entry with multilib flag 0. * gcc.cc (do_spec_1): If multiarch_dir, add include-fixed/multiarch_dir paths before include-fixed paths.=