search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Headers/arm-fp16-header.c & Headers/arm-neon-header.c tests fail on ppc64 #39792

Open Quuxplusone opened 5 years ago

Quuxplusone commented 5 years ago
Bugzilla Link PR40821
Status NEW
Importance P normal
Reported by Michał Górny (mgorny@gentoo.org)
Reported on 2019-02-22 08:32:36 -0800
Last modified on 2019-02-25 02:21:17 -0800
Version trunk
Hardware PC Linux
CC diogo.sampaio@arm.com, efriedma@quicinc.com, htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk, smithp352@googlemail.com
Fixed by commit(s)
Attachments clang-8.0.0_rc2_20190222-115204.log.xz (189700 bytes, application/x-xz)
Blocks
Blocked by
See also https://bugs.gentoo.org/show_bug.cgi?id=678568 
Created attachment 21505
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.
Quuxplusone commented 5 years ago

Attached clang-8.0.0_rc2_20190222-115204.log.xz (189700 bytes, application/x-xz): clang-8.0.0_rc2_20190222-115204.log.xz

Quuxplusone commented 5 years ago

Tests shouldn't be including system headers. In this case, they should probably be using -ffreestanding.

Quuxplusone commented 5 years ago 
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
Quuxplusone commented 5 years ago

Thanks for the suggestion, I'll pass it on.

Quuxplusone commented 5 years ago 
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.
Quuxplusone commented 5 years ago

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.