https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122411
Bug ID: 122411
Summary: Empty path in COMPILER_PATH leads to -isystem
./include
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: p.e.c.melis at alumnus dot utwente.nl
Target Milestone: ---
We had inadvertently set COMPILER_PATH to "<somepath>:" (i.e. with trailing
":") and this leads to `-isystem ./include` being added by cpp/gcc, but only
when directory `include` actually exists in the current directory.
paulm@l0420007 11:24:~$ ls -l include
total 0
paulm@l0420007 11:24:~$ COMPILER_PATH=/tmp: cpp -v
Using built-in specs.
COLLECT_GCC=cpp
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.2.1 20250813 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/cc1 -E -quiet -v -isystem ./include -
-mtune=generic -march=x86-64 -dumpbase -
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
./include
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/include-fixed
/usr/include
End of search list.
^C
However, if ./include does not exist no warning of non-existance is given and
`-isystem ./include` is not added, which is thoroughly confusing:
paulm@l0420007 11:28:~$ rm -rf include/
paulm@l0420007 11:29:~$ COMPILER_PATH=/tmp: cpp -v
Using built-in specs.
COLLECT_GCC=cpp
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.2.1 20250813 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/cc1 -E -quiet -v - -mtune=generic
-march=x86-64 -dumpbase -
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/include-fixed
/usr/include
End of search list.
^C
Clearly that empty entry should not be there from our side, but it lead to a
long search for why a build was breaking which had an `include` dir in the
build dir that was referenced `-I./include`. But this `-I` was getting ignored
as it was treated as a duplicate system include path and thus moved later in
the include path list.
The current behaviour is a bit buggy in my opinion:
- The documentation for COMPILER_PATH only mentions that it influences
"searching for subprograms", but says nothing of it influencing (system)
include directories.
- No warning is given that `./include` cannot be found when it doesn't exist,
even though that seems to be the default behaviour for other non-existent
directories that are searched (but not those from COMPILER_PATH). Together with
silently adding `-isystem ./include` when `include` exists is quite unexpected.
