GCC 14 generates incorrect include directories

[kolerov]

Here is an example:

$ riscv64-unknown-elf-gcc main.c -v
Using built-in specs.
COLLECT_GCC=/tools/gcc-arcv-newlib-dev/bin/riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/tools/gcc-arcv-newlib-dev/libexec/gcc/riscv64-unknown-elf/14.1.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /home/ykolerov/workspace/development/sources/gcc-arcv/configure --target=riscv64-unknown-elf --prefix=/tools/gcc-arcv-newlib-dev --disable-shared --disable-threads --enable-languages=c,c++ --with-pkgversion=gccdcd94e8db --with-system-zlib --enable-tls --with-newlib --with-sysroot=/tools/gcc-arcv-newlib-dev/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=/home/ykolerov/workspace/development/sources/gcc-arcv --enable-multilib --with-multilib-generator='rv32imac-ilp32--;rv64imac-lp64--; --cmodel=medany' --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-Os    ' 'CXXFLAGS_FOR_TARGET=-Os    '
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.1.0 (gccdcd94e8db)
COLLECT_GCC_OPTIONS='-v' '-mtune=rocket' '-march=rv64imafdc_zicsr' '-mabi=lp64d' '-misa-spec=20191213' '-march=rv64imafdc_zicsr' '-dumpdir' 'a-'
 /tools/gcc-arcv-newlib-dev/libexec/gcc/riscv64-unknown-elf/14.1.0/cc1 -quiet -v -imultilib . main.c -quiet -dumpdir a- -dumpbase main.c -dumpbase-ext .c -mtune=rocket -march=rv64imafdc_zicsr -mabi=lp64d -misa-spec=20191213 -march=rv64imafdc_zicsr -version -o /tmp/ccoRTKWL.s
GNU C17 (gccdcd94e8db) version 14.1.0 (riscv64-unknown-elf)
        compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/tools/gcc-arcv-newlib-dev/riscv64-unknown-elf/usr/local/include"
ignoring duplicate directory "/tools/gcc-arcv-newlib-dev/riscv64-unknown-elf/include"
...

GCC is configured with --with-sysroot=/tools/gcc-arcv-newlib-dev/riscv64-unknown-elf and --with-native-system-header-dir=/include but GCC tries to get access to /tools/gcc-arcv-newlib-dev/riscv64-unknown-elf/usr/local/include which is a concatenation of a valid --with-sysroot and invalid --with-native-system-header-dir. This may be reproduced in a toolchain built with the latest riscv-gnu-toolchain or Crosstool-NG scripts.

Here is how this may be reproduced (it's necessary to pass a path to GCC 14 source since RISC-V scripts still use GCC 13):

$ git clone https://github.com/riscv-collab/riscv-gnu-toolchain
$ cd riscv-gnu-toolchain
$ ./configure --prefix=/tools/gcc-riscv-newlib-dev --with-gcc-src=<path/to/gcc14>
$ make
$ /tools/gcc-riscv-newlib-dev/bin/riscv64-unknown-elf-gcc main.c -save-temps -v
...
ignoring nonexistent directory "/tools/gcc-riscv-newlib-dev/riscv64-unknown-elf/usr/local/include"
ignoring duplicate directory "/tools/gcc-riscv-newlib-dev/riscv64-unknown-elf/include"
...

This bug was introduced in our build after this patch: foss-for-synopsys-dwc-arc-processors/crosstool-ng@5419c9c
It forces Crosstool-NG scripts to build GCC with --with-sysroot and --with-native-system-header-dir options and actually it's right and RISC-V scripts do the same thing. But something wrong happens when GCC 14 is built with those options both in RISC-V original scripts and in Crosstool-NG.

[kolerov]

I marked this issue as related to non-Synopsys code. Since it’s not critical this may be skipped for this release.

[abrodkin]

@kolerov that needs to go into known issues so that our users are aware of that. Also would be super nice to file an upstream bug for that.

[kolerov]

@abrodkin I updated the release page with detailed description. I will also report to upstream project.

[kolerov]

I've created a new branch for arc-2024.12 with a fix for this issue: https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng/tree/arc-2024.12. I tried to find a root cause or even to explain a nature of this issue but I've not succeeded.

In short, the problem was in this commit foss-for-synopsys-dwc-arc-processors/crosstool-ng@5419c9c. It fixed canadian builds but broke other toolchain types. So, the easiest workaround here is just to use libstdc++ fix only for canadian builds.

[abrodkin]

@kolerov are we suggesting that fix for the upstream CT-NG?
I guess it's the right time to switch to that new https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng/tree/arc-2024.12 branch for our daily and weekly toolchain builds before it's not too late for this release cycle.

[kolerov]

@abrodkin I've already asked @yaroslavsadin to switch to arc-2024.12. The original issue was closed without a resolution. Then the author created a new one and it's still opened. So, the original fix for canadian builds is not even in upstream. And my patch is "a fix for a fix".

Regarding the issue itself I can only say that it's somehow related to these bugs:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56279
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56280

They were created more than 10 years ago, and they have not been resolved.

[kolerov]

Daily builds a switched to arc-2024.12 branch. Now latest toolchain builds use valid include paths.