public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "helmut at subdivi dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file Date: Mon, 31 Oct 2022 09:46:07 +0000 [thread overview] Message-ID: <bug-80755-4-8q8JRsfIKf@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-80755-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 Helmut Grohne <helmut at subdivi dot de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |helmut at subdivi dot de --- Comment #2 from Helmut Grohne <helmut at subdivi dot de> --- Created attachment 53801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53801&action=edit proposed fix I confirm the issue on gcc 12.2.0-3 on Debian and have seen it since at least version 11. The symptom is slightly different though. It no longer produces an ICE. Instead the output looks like this: lastincdir/testcase.h:1:24: error: no include path in which to search for doesnotexist.h ... (null):0: confused by earlier errors, bailing out The invocation terminates with status 1. While this no longer is an ICE, the behavior is not correct either. __has_include_next should not error out and return false-ish instead. I believe that looking at the attached patch makes the problem fairly obvious. This problem now affects toolchain bootstrap on Debian for hurd architectures. The stage1 preprocessor happens to run into this very early.
next parent reply other threads:[~2022-10-31 9:46 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-80755-4@http.gcc.gnu.org/bugzilla/> 2022-10-31 9:46 ` helmut at subdivi dot de [this message] 2023-12-18 4:58 ` sjames at gcc dot gnu.org 2023-12-21 12:39 ` lhyatt at gcc dot gnu.org 2024-02-27 23:42 ` sjames at gcc dot gnu.org 2024-02-28 0:10 ` lhyatt at gcc dot gnu.org 2024-03-14 11:33 ` cvs-commit at gcc dot gnu.org 2024-03-14 11:35 ` lhyatt at gcc dot gnu.org
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=bug-80755-4-8q8JRsfIKf@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).