public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>,
	Jason Merrill <jason@redhat.com>,
	"Joseph S. Myers" <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Tobias Burnus <tobias@codesourcery.com>
Subject: [PATCH] driver, cppdefault: Unbreak bootstrap on Debian/Ubuntu [PR107059]
Date: Thu, 29 Sep 2022 09:06:48 +0200	[thread overview]
Message-ID: <YzVECKV7e5nDSA0S@tucnak> (raw)

Hi!

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 initializer
means the entry is ignored on non-multiarch and suffixed by the multiarch
dir otherwise, so installed gcc has search path like:
 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include
 /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=/home/jakub/gcc/obj01inst).
Now, when fixincludes is run, it is processing the whole /usr/include dir
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 <bits/floatn.h>
given the above search path, it doesn't find the fixincluded header,
as
/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
/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:
 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include
 /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu
 /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.

Bootstrapped/regtested on x86_64-linux (Debian on GCCFarm, though with the
/usr/include/bits -> x86_64-linux-gnu/bits symlink).  Ok for trunk?

2022-09-29  Jakub Jelinek  <jakub@redhat.com>

	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.

--- gcc/cppdefault.cc.jj	2022-01-18 11:58:59.411984500 +0100
+++ gcc/cppdefault.cc	2022-09-28 12:11:47.923603783 +0200
@@ -74,6 +74,9 @@ const struct default_include cpp_include
 #endif
 #ifdef FIXED_INCLUDE_DIR
     /* This is the dir for fixincludes.  */
+#ifndef SYSROOT_HEADERS_SUFFIX_SPEC
+    { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, 2 },
+#endif
     { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
       /* A multilib suffix needs adding if different multilibs use
 	 different headers.  */
--- gcc/gcc.cc	2022-09-23 09:02:56.809314447 +0200
+++ gcc/gcc.cc	2022-09-28 21:02:29.751933657 +0200
@@ -6400,6 +6400,18 @@ do_spec_1 (const char *spec, int inswitc
 	      if (*sysroot_hdrs_suffix_spec)
 		info.append = concat (info.append, dir_separator_str,
 				      multilib_dir, NULL);
+	      else if (multiarch_dir)
+		{
+		  /* For multiarch, search include-fixed/<multiarch-dir>
+		     before include-fixed.  */
+		  info.append = concat (info.append, dir_separator_str,
+					multiarch_dir, NULL);
+		  info.append_len = strlen (info.append);
+		  for_each_path (&include_prefixes, false, info.append_len,
+				 spec_path, &info);
+
+		  info.append = "include-fixed";
+		}
 	      info.append_len = strlen (info.append);
 	      for_each_path (&include_prefixes, false, info.append_len,
 			     spec_path, &info);

	Jakub


             reply	other threads:[~2022-09-29  7:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29  7:06 Jakub Jelinek [this message]
2022-09-29  8:26 ` Richard Biener
2022-09-29  9:23 ` Tobias Burnus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YzVECKV7e5nDSA0S@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=rguenther@suse.de \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).