Dear testers,
8.0.0-rc2 has been tagged from the release_80 branch at r353413.
Please run the test script, share your results, and upload binaries.
I'll get the source tarballs and docs published as soon as possible,
and binaries as they become available.
Thanks,
Hans
Hello,
We have started to build the 8.x branch and part of our build process is to run check-clang, check-llvm and check-lld on Linux, Windows, Macos and FreeBSD. Is there a test report or file we can collect in the CI and share with the community if there is interest?
Hi Tobias,
Thank you for testing the release branch!
The test runner doesn't produce any report file. If you want to share
results, what is interesting for us is the output of the check-llvm,
etc. steps in the cases there are test failures.
Thanks,
Hans
----- Oryginalna wiadomość -----
Dear testers,
8.0.0-rc2 has been tagged from the release_80 branch at r353413.
Hi,
i've noticed a compile error with rc2 and libc++ (release_80 @svn). looks similar to 40559 – Predefined __FLT16_MANT_DIG__ defined on targets that don't support _Float16
(...)/clang++ -fPIC -target x86_64-linux-gnu --sysroot=(...) -march=x86-64 -fuse-ld=lld -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR -D_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS -stdlib=libc++ -std=gnu++1z -flto=thin
(...)
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/string:500:
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/string_view:176:
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/__string:56:
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/algorithm:640:
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/initializer_list:47:
In file included from (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/cstddef:110:
(...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/type_traits:740:56: error: _Float16 is not supported on this target
template <> struct __libcpp_is_floating_point<_Float16> : public true_type {};
^
rc2 build on Ubuntu 16.04 saw a stage 2/3 mismatch on X86IselLowering.cpp.o – I didn’t try to build rc1 for 16.04 but I can try it now to see if it’s there too.
I can pass along logs if anyone wants to investigate.
I’ll take a look at this
rc1 did not exhibit this mismatch. A repeat of the rc2 build repeated the mismatch. I diff’d the disassembly between phase 2 and phase 3 and the difference is the same on both builds. The difference follows:
2c2
< Phase2/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64
This is quite odd, because libc++ trunk has no mentions of _Float16, and I see none here:
https://llvm.org/svn/llvm-project/libcxx/branches/release_80/include/type_traits
– Marshall
----- Oryginalna wiadomość -----
Uploaded ARM & AArch64:
9432315fe814e5edc667467bc1b3ce4817084edc
clang+llvm-8.0.0-rc2-aarch64-linux-gnu.tar.xz
fb7f587de673837c82da47209ec9d9ed72f9b27f
clang+llvm-8.0.0-rc2-armv7a-linux-gnueabihf.tar.xz
Same as before, ARM looks fine but we have a MSan failure on AArch64
(I haven't yet managed to reproduce it outside Jenkins though, I'll
try harder).
Cheers,
Diana
Any tips or suggestions on how to isolate or identify this defect? It seems non-trivial to bisect this failure.
Hans: presumably this bug should block the 8.0 release?
If each stage consistently produces the same object file, then treat it like any other miscompile: mix the object files created by a good/bad compiler to bisect which C++ file is getting miscompiled, then reduce the failure using opt-bisect-limit or bugpoint. Or maybe you could try asan/ubsan first to rule out something silly.
If it’s non-determinism, you could try to use opt-bisect-limit to figure out which pass is non-deterministic.
-Eli
I've filed 40714 – 8.0.0-rc2 binary diff between stage 2 and stage 3 in X86ISelLowering.cpp.o to track this.
Unfortunately I had to disable compiler-rt for this test run, as most of the sanitizers are totally broken. They get into an endless recursive loop between AsanTSDGet() and the __tls_get_addr() interceptor, and crash with DEADLYSIGNAL due to stack overflow. I haven't found the time to further diagnose this.
Main test results on amd64-freebsd11:
Expected Passes : 53882
Expected Failures : 220
Unsupported Tests : 1081
Unresolved Tests : 10
Unexpected Passes : 3
Unexpected Failures: 60
Main test results on i386-freebsd11:
Expected Passes : 53729
Expected Failures : 236
Unsupported Tests : 903
Unresolved Tests : 10
Unexpected Passes : 5
Unexpected Failures: 178
The unresolved tests are due to a number of tests hanging in <defunct> state, forcing me to kill their parent .py processes.
Uploaded:
SHA256 (clang+llvm-8.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 81673933ecd33f22f45a3ffa4558f3a23e9dbb8c3a0255ec831c8dd6c97b0bae
SHA256 (clang+llvm-8.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 663f340568a5c06470616008cdd7c5c118eb64d6acfc80009d5cc2b596fb6242
-Dimitry
wrote:>> On 7 Feb 2019, at 16:41, Hans Wennborg via Release-testers
<release-testers@lists.llvm.org> wrote:> > 8.0.0-rc2 has been tagged
from the release_80 branch at r353413.> >> > Please run the test
script, share your results, and upload binaries.>> Unfortunately I had
to disable compiler-rt for this test run, as most of the sanitizers
are totally broken. They get into an endless recursive loop between
AsanTSDGet() and the __tls_get_addr() interceptor, and crash with
DEADLYSIGNAL due to stack overflow. I haven't found the time to
further diagnose this.:-/ I don't remember hearing this before, so
sounds like it's a regression from rc1? Even if you don't have time to
investigate right now, can you please file a bug to make sure I don't
forget?
Main test results on amd64-freebsd11:
Expected Passes : 53882
Expected Failures : 220
Unsupported Tests : 1081
Unresolved Tests : 10
Unexpected Passes : 3
Unexpected Failures: 60Main test results on i386-freebsd11:
Expected Passes : 53729
Expected Failures : 236
Unsupported Tests : 903
Unresolved Tests : 10
Unexpected Passes : 5
Unexpected Failures: 178The unresolved tests are due to a number of tests hanging in <defunct> state, forcing me to kill their parent .py processes.
Uploaded:
SHA256 (clang+llvm-8.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 81673933ecd33f22f45a3ffa4558f3a23e9dbb8c3a0255ec831c8dd6c97b0bae
SHA256 (clang+llvm-8.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 663f340568a5c06470616008cdd7c5c118eb64d6acfc80009d5cc2b596fb6242
Added to the pre-release page.
Thanks,
Hans
Filed https://bugs.llvm.org/show_bug.cgi?id=40761 to track this.