This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
- From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 19 May 2017 09:01:41 +0000
- Subject: [Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
- Auto-submitted: auto-generated
- References: <bug-80759-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
Daniel,
> Would you be so kind as to test this on Solaris for me please? I don't have
> access to a Solaris machine and I've never set it up before, so I wouldn't even
> know where to start to try to build an OpensSolaris VM.
sure, though there's no need at all (except for the .struct part) to do
the testing on Solaris. I believe there are ready-made Solaris/x86
VirtualBox images, though. For the multilib problem, you can easily
configure gcc for i686-pc-linux-gnu with --enable-targets=all on a
Linux/x86_64 box (with a few necessary 32-bit development packages
added), so the default multilib is non-x86_64, while the x86_64 multilib
is only used with -m64.
I gave your patch a quick whirl on i386-pc-solaris2.12 (with /bin/as),
and just that multilib problem is still unfixed. For the (default)
32-bit multilib, the test is skipped as should be, but for the 64-bit
multilib, compilations still lack the required -m64, so they fail with
spawn /var/gcc/regression/trunk/12-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/12-gcc/build/gcc/
-I/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv
-I/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -Wall -c -o
/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc/ms-sysv/ms-sysv.o
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:62:3:
error: #error Test only valid on x86_64^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:102:5:
error: unknown type name '__uint128_t'^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:34:
error: unknown type name '__uint128_t'^M
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:56:
error: unknown type name '__uint128_t'^M
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-O2" generator_args="-p0-5"
as before. To check how things were otherwise, I just manually
assembled/compiled do-test.S and ms-sysv.c with -m64, linked them into
ms-sysv.exe, which ran successfully, so it seems were getting closer.
However, I still don't understand why you are jumping through all these
hoops in ms-sysv.exp doing the compilations etc. manually rather than
just relying on dg-runtest or similar. This would avoid all this
multilib trouble nicely, and massivly reduce ms-sysv.exp.
One or two nits about PR management, btw.: it is good practice to take
the PR if you're working on it. And just add the URL to the patch
submissing into the URL field.
Thanks.
Rainer