* Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the last version that can build without C++11 support), and it crashes with a segfault during building of CGBlocks.cpp. I'll need to find some way to work around this failure, since we cannot upgrade the compiler easily on FreeBSD 10.x.
This sounds like the biggest problem. Is there a PR for the crash? I
suppose the alternatives are either to try not to tickle the crash in
our source, or fixing the 3.4.1 compiler?
There is no PR, but I did a bisection, and the crash turns out to be fixed by r210467 ("[DAG] Expose NoSignedWrap, NoUnsignedWrap and Exact flags to SelectionDAG.") by Andrea DiBiagio.
And I finally found out this was a red herring, and I had already solved this issue before, in July 2015 [1], with excellent help from Andrea! This was originally known as PR24249, and eventually turned out to be solved by llvm r219009.
However, the two build VMs I have been using for LLVM release testing were never updated to include the fix, and were still at the version of FreeBSD from roughly May 2015.
I have now been able to do a successful build of the llvm, clang and (for amd64) openmp. Uploaded the following tarballs:
I would like to take a look at the errors, can you send me the full output?
Unfortunatly I no longer have a FreeBSD machine to test on, but I think
it's important libc++ gets/keeps the test suite clean on FreeBSD.
Uploaded Win binaries to the sftp:
842c6b6165089cd0771020c0bdb542456690aab9 LLVM-3.8.0-rc1-win32.exe
5031bd338856b3cd06fce260c9cc1c2445536963 LLVM-3.8.0-rc1-win64.exe
Looks like I see several failures that weren’t in 3.7.1. Is there any way to tell whether these are regressions vs new-to-3.8.0-but-failing? The MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were not in 3.7.1.
Looks like I see several failures that weren't in 3.7.1. Is there any way
to tell whether these are regressions vs new-to-3.8.0-but-failing? The
MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
not in 3.7.1.
All of the libc++ failures seem like non-issues and should be in 3.7.1. Did
you change or upgrade your platform or libc version? I'm not sure about
the libc++abi error though.
These are marked XFAIL on open-suse, They should probably be marked as
XFAIL on your platform as well.
Can you send me the output of Python's "platform.linux_distribution()"?
libc++abi :: cxa_thread_atexit_test.pass.cpp
Not sure about this failure. Can you send me the output?
Looks like I see several failures that weren't in 3.7.1. Is there any
way to tell whether these are regressions vs new-to-3.8.0-but-failing? The
MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
not in 3.7.1.
All of the libc++ failures seem like non-issues and should be in 3.7.1.
Did you change or upgrade your platform or libc version? I'm not sure
about the libc++abi error though.
I don't recall any changes to libc. Attached is the testing log from 3.7.1
rc2 (I don't have logs from -final handy).
I can repeat a 3.7.1 release build on this system now. I don't think the
results will change, though.
These are marked XFAIL on open-suse, They should probably be marked as
XFAIL on your platform as well.
Can you send me the output of Python's "platform.linux_distribution()"?
Ok, I'll be able to get this tomorrow. But I suspect it will be "('SUSE
Linux Enterprise Server ', '11', 'x86_64')"
libc++abi :: cxa_thread_atexit_test.pass.cpp
Not sure about this failure. Can you send me the output?
That one failed in 3.7.1 also. IIRC this libstdc++ doesn't have
cxa_thread_atexit.
Uploaded in Debian. Waiting for approval as it is a new package.
By the way, I'd like to mention that it is the first upload in Debian
(and therefor Ubuntu) to be built with Cmake. I would like
to send a HUGE thanks to Andrew Wilkins who did all the work!
Many thanks. This also means that compiler-rt should be back soon
on http://llvm.org/apt/
However, under Debian amd64, the following clang tests are failing
Clang :: CodeGen/address-safety-attr.cpp
Clang :: CodeGen/asan-globals.cpp
Clang :: CodeGen/linux-arm-atomic.c
Clang :: CodeGen/sanitize-init-order.cpp
Clang :: CodeGen/sanitize-thread-attr.cpp
Clang :: CodeGen/ubsan-blacklist.c
Clang :: Driver/arm-features.c
Clang :: Driver/arm-ias-Wa.s
Clang :: Driver/arm-mfpu.c
Clang :: Preprocessor/arm-acle-6.5.c
Clang :: Preprocessor/arm-target-features.c
I discussed this more with Eric off-list and I think we've come to the
conclusion that this was not a regression, it was my error.
It's a bit tricky -- what should I expect for a new platform? All failing
tests are likely failing because they can't be/aren't yet supported? It's
tough to distinguish -- are they real bugs to be fixed, errors in the
build/release process?
I built rc1 on Ubuntu 15.04 armhf. Many tests fail (560, nearly all are libc++ and libc++abi). There’s also a handful of unexpected passing tests (12).
clang+llvm-3.8.0-rc1-mips-linux-gnu.tar.xz
test-release.sh refused to run 'make check-all' because libcxx_tsan failed to configure. This is because the thread sanitizer is not supported on MIPS32.
After working around this (patch will follow shortly):
~200 sanitizer failures. Most of them tsan (which as noted above shouldn't be running), but other sanitizers too.
lots of libc++ failures split into two cases:
(No ticket yet) - Missing builtins for 64-bit atomics. Vasileios Kalintiris has given me a patch that should fix this
PR26277 - Some diagnostic checking tests fail because the assembler can't find it's input file. Clang didn't create it due to frontend errors but still called GAS.
clang+llvm-3.8.0-rc1-mipsel-linux-gnu.tar.xz
lots of libc++ failures split into two cases:
(No ticket yet) - Missing builtins for 64-bit atomics. Vasileios Kalintiris has given me a patch that should fix this
PR26277 - Some diagnostic checking tests fail because the assembler can't find it's input file. Clang didn't create it due to frontend errors but still called GAS.
Test-suite was ok.
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (native X86_64)
PR26252 - libc++ fails 23 tests due to missing en_US-UTF8 locale. I have two patches in progress for this and I've also made the problem go away by enabling this locale.
PR26253 - libomp fails runtime/test/barrier/omp_barrier.c
Test-suite was ok
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (cross compiling to Mips)
10/23 test-suite configs ok. The rest are still running.
Ideally, all tests should pass on the platforms we build for. In your
case, it's not even very exotic, just x86_64 Linux. The LLVM and Clang
tests are pretty good in this regard, but various sanitizer and libc++
tests seem less stable. In practice, we've been releasing as long as
the failures don't look like regressions from previous releases.
The test-suite shouldn’t be being build with CMake for the release - the CMake system is not yet ready. Have you accidentally checked out the test-suite into /projects? if it’s there it will auto-configure.
It seems that test-release was fixed, thanks everyone. Builds are OK but I’d like to know where did test-suite go? All I see is the llvm.src directory, am I supposed to export test-suite myself?