Created attachment 21505 [details] clang-8.0.0_rc2_20190222-115204.log.xz Proxying a bug reported by Gentoo ppc64 user. Failing Tests (2): Clang :: Headers/arm-fp16-header.c Clang :: Headers/arm-neon-header.c Apparently the tests somehow depend on glibc having 32-bit stubs (?) on non-ARM platforms. I'm pasting the most relevant error below, and attaching a full build log. Command Output (stderr): -- + : 'RUN: at line 1' + /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/clang -fsyntax-only -ffreestanding --target=aarch64-none-eabi -march=armv8.2-a+fp16 -std=c89 -xc /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src/test/Headers/arm-fp16-header.c In file included from /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src/test/Headers/arm-fp16-header.c:19: In file included from /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/../../../../lib/clang/8.0.0/include/arm_fp16.h:27: In file included from /usr/include/stdint.h:26: In file included from /usr/include/bits/libc-header-start.h:33: In file included from /usr/include/features.h:452: /usr/include/gnu/stubs.h:8:11: fatal error: 'gnu/stubs-32.h' file not found # include <gnu/stubs-32.h> ^~~~~~~~~~~~~~~~ 1 error generated.
Tests shouldn't be including system headers. In this case, they should probably be using -ffreestanding.
The only way that test could fail in that way is if the host stdint.h got picked up by mistake, yet all the macros are defined for a 32-bit ARM system, hence the request for 32-bit stubs. The test is using -ffreestanding so the clang stdint.h shouldn't be including the host one. That leaves us with the possibility that the headers aren't in the right location or the 8.0.0 test isn't using -ffreestanding . Running the test locally on trunk (Ubuntu 16.04 X86_64) with -v to see what the include paths are I get: #include "..." search starts here: #include <...> search starts here: /usr/local/include /path/to/my/llvm/build/lib/clang/9.0.0/include /usr/include There is a stdint.h in the clang/9.0.0/include directory that shouldn't cause this problem. The next line is /usr/include where the host stdint.h lives. I've not got a PPC system or 8.0.0_rc2 around to test right now and the network at the office is going down in 5 minutes. My suggestion is to ask the reporter to run one of the tests individually and look for the search path with -v. Then check to see if clang/8.0.0/include contains stdint.h
Thanks for the suggestion, I'll pass it on.
Indeed it seems that something is really wrong there: # /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/clang -v -fsyntax-only -ffreestanding --target=aarch64-none-eabi -march=armv8.2-a+fp16 -std=c89 -xc -E test.c clang version 8.0.0 (tags/RELEASE_800/rc2) Target: aarch64-none-unknown-eabi Thread model: posix InstalledDir: /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin clang-8: warning: argument unused during compilation: '-fsyntax-only' [-Wunused-command-line-argument] "/var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/clang-8" -cc1 -triple aarch64-none-unknown-eabi -E -disable-free -main-file-name test.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -ffreestanding -fuse-init-array -target-cpu generic -target-feature +neon -target-feature +v8.2a -target-feature +fullfp16 -target-abi aapcs -fallow-half-arguments-and-returns -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/../../../../lib/clang/8.0.0 -std=c89 -fdebug-compilation-dir /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/test -ferror-limit 19 -fmessage-length 132 -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o - -x c test.c clang -cc1 version 8.0.0 based upon LLVM 8.0.0 default target powerpc64-unknown-linux-gnu ignoring duplicate directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/include /usr/local/include /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/../../../../lib/clang/8.0.0/include End of search list. In file included from test.c:1: In file included from /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/../../../../lib/clang/8.0.0/include/arm_fp16.h:27: In file included from /usr/include/stdint.h:26: In file included from /usr/include/bits/libc-header-start.h:33: In file included from /usr/include/features.h:452: /usr/include/gnu/stubs.h:8:11: fatal error: 'gnu/stubs-32.h' file not found # include <gnu/stubs-32.h> ^~~~~~~~~~~~~~~~ [cut] So apparently /usr/include is taken before clang include dir.
I don't have a lot of ideas as to how that would happen. As far as I can tell the code that generates those paths is in InitHeaderSearch::AddDefaultCIncludePaths from InitHeaderSearch.cpp and that adds the /usr/local/include, resource-dir, /usr/include in that order. It seems like all those directories are present in the -v output but the order has been scrambled. I've not got access to a PPC system to find out how. I think this needs a PPC expert with a debugger, to work out where the order gets changed.