[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[lhyatt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.0

--- Comment #8 from Lewis Hyatt  ---
Fixed for GCC 14.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:6c166e55b15894ceb07dcc7b55f900e50e24ec5b

commit r14-9464-g6c166e55b15894ceb07dcc7b55f900e50e24ec5b
Author: Lewis Hyatt 
Date:   Wed Dec 20 16:27:42 2023 -0500

libcpp: Fix __has_include_next ICE in the last directory of the path
[PR80755]

In libcpp/files.cc, the function _cpp_has_header(), which implements
__has_include and __has_include_next, does not check for a NULL return
value
from search_path_head(), leading to an ICE tripping an assert when
_cpp_find_file() tries to use it. Fix it by checking for that case and
silently returning false instead.

As suggested by the PR author, it is easiest to make a testcase by using
the -idirafter option. To enable that, also modify the
dg-additional-options
testsuite procedure to make the global $srcdir available, since -idirafter
requires the full path.

libcpp/ChangeLog:

PR preprocessor/80755
* files.cc (search_path_head): Add SUPPRESS_DIAGNOSTIC argument
defaulting to false.
(_cpp_has_header): Silently return false if the search path has
been
exhausted, rather than issuing a diagnostic and then hitting an
assert.

gcc/testsuite/ChangeLog:

* lib/gcc-defs.exp (dg-additional-options): Make $srcdir usable in
a
dg-additional-options directive.
* c-c++-common/cpp/has-include-next-2-dir/has-include-next-2.h: New
test.
* c-c++-common/cpp/has-include-next-2.c: New test.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[lhyatt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

--- Comment #6 from Lewis Hyatt  ---
(In reply to Sam James from comment #5)
> Thank you Lewis!
> 
> Would you mind pinging this again?
> 
> I've just started hitting this on glibc systems too as we added a wrapper to
> a libbsd header (which I'm probably going to have to drop for now).

Sure, I tried...
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646695.html. I think
reviewers are probably focused on other things for the GCC 14 release though, I
have 3 or 4 libcpp patches that have been waiting for months now, and they may
not make it into 14.0 if they aren't regressions. It may help if you chime in
on the gcc-patches thread as well?

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

--- Comment #5 from Sam James  ---
Thank you Lewis!

Would you mind pinging this again?

I've just started hitting this on glibc systems too as we added a wrapper to a
libbsd header (which I'm probably going to have to drop for now).

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[lhyatt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

Lewis Hyatt  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-21
 Ever confirmed|0   |1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/641247.html
 CC||lhyatt at gcc dot gnu.org
   Keywords||patch
 Status|UNCONFIRMED |NEW

--- Comment #4 from Lewis Hyatt  ---
Submitted a patch for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=920233

--- Comment #3 from Sam James  ---
We seem to have had another report of this downstream in Gentoo at
https://bugs.gentoo.org/920233 on musl systems.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[helmut at subdivi dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

Helmut Grohne  changed:

   What|Removed |Added

 CC||helmut at subdivi dot de

--- Comment #2 from Helmut Grohne  ---
Created attachment 53801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53801=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.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[p...@gcc-bugzilla.mail.kapsi.fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755

--- Comment #1 from Pekka S  ---
Created attachment 41359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41359=edit
trips __has_include_next. must be placed under last-include-dir/