Hi,
I just tagged 3.9.1-rc2, so testing can begin. There was a bug found in
-rc1 before I could send out a release announcement, so I decided to merge
the fix and tag -rc2 to save some testing cycles.
We can always use more testers, so if you are interested in helping, let
me know.
Thanks,
Tom
AArch64 RC2 validated and uploaded.
MD5: 4112d2cc3cd6f390d61c9db8f2897f64
clang+llvm-3.9.1-rc2-aarch64-linux-gnu.tar.xz
ARM RC2 validated and uploaded.
Found a bug fixed by r283299. Created PR31238. Backported as r288513.
MD5: 5c91906438dd39889df55328496a66ed
clang+llvm-3.9.1-rc2-armv7a-linux-gnueabihf.tar.xz
Everything else, clean.
cheers,
--renato
Windows looks good and the binaries are uploaded: (sha1sum)
0d0425c3e77ddad8b885ceb66513a3ab85738da8 LLVM-3.9.1-rc2-win32.exe
efc721b59fdfe4b51a71800966c70a872efe897f LLVM-3.9.1-rc2-win64.exe
They were built with the attached batch file.
Cheers,
Hans
build_llvm_391-rc2.bat|attachment (3.5 KB)
Built and tested OK on FreeBSD 10:
SHA256 (clang+llvm-3.9.1-rc2-i386-unknown-freebsd10.tar.xz) = 4539345f89d75a18845b6e64dbcea7db20d841829e7b9d6dd02af35f7e003d53
SHA256 (clang+llvm-3.9.1-rc2-amd64-unknown-freebsd10.tar.xz) = aae2a3df36af6d92b509a7c070a4cdd6491b298d3b599f6a6b28ef2ca43eccf0
-Dimitry
Hi Tom,
There is a bug in upstream LLVM that existed in LLVM 3.9.0 as well so
it likely exists in the 3.9.1 rc too.
I've just put the patch up for review (
https://reviews.llvm.org/D27393 ). Once a fix is approved you may want
to back port it to the 3.9 release branch.
Thanks,
Dan.
Here’s the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I’ve done some amount of triaging what some critical elements of the failures are. Unabridged log is attached.
Failing Tests (94):
LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt
LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool
LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestSerialization
LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
All of these ^^ failed with:
terminate called after throwing an instance of ‘std::future_error’
what(): No associated state
AddressSanitizer-x86_64-linux :: TestCases/Linux/interface_symbols_linux.c
This fails with “sed: invalid option – ‘E’”. The OS X manpage (https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/sed.1.html) says “The -E, -a and -i options are non-standard FreeBSD extensions and may not be available on other operating systems.” It’s present in GNU sed 4.2.2 but absent from sed 4.1.5 on SLES11.3.
AddressSanitizer-x86_64-linux :: TestCases/Linux/new_delete_mismatch.cc
This fails with “syntax error near unexpected token `&’” because “|&” shortcut is not yet supported in bash 3.2.
Clang Tools :: include-fixer/include_path.cpp
Clang Tools :: include-fixer/merge.test
LLVM :: ExecutionEngine/MCJIT/remote/cross-module-a.ll
LLVM :: ExecutionEngine/MCJIT/remote/eh.ll
LLVM :: ExecutionEngine/MCJIT/remote/multi-module-a.ll
LLVM :: ExecutionEngine/MCJIT/remote/simpletest-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/stubs-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-common-symbols-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-data-align-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-fp-no-external-funcs-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-global-init-nonzero-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-global-init-nonzero-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-ptr-reloc-remote.ll
LLVM :: ExecutionEngine/MCJIT/remote/test-ptr-reloc-sm-pic.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/cross-module-a.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/eh.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/multi-module-a.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/simpletest-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/stubs-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-common-symbols-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-data-align-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-fp-no-external-funcs-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-global-init-nonzero-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-global-init-nonzero-sm-pic.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-ptr-reloc-remote.ll
LLVM :: ExecutionEngine/OrcMCJIT/remote/test-ptr-reloc-sm-pic.ll
LLVM :: LTO/X86/parallel.ll
LLVM :: ThinLTO/X86/cache.ll
LLVM :: ThinLTO/X86/funcimport.ll
LLVM :: tools/llvm-cov/binary-formats.c
LLVM :: tools/llvm-cov/combine_expansions.cpp
LLVM :: tools/llvm-cov/cov-comdat.test
LLVM :: tools/llvm-cov/demangle.test
LLVM :: tools/llvm-cov/double_dots.c
LLVM :: tools/llvm-cov/prefer_used_to_unused.h
LLVM :: tools/llvm-cov/prevent_false_instantiations.h
All of these ^^ also fail with “terminate called after throwing an instance of ‘std::future_error’ what(): No associated state”.
LLVM :: tools/llvm-cov/showExpansions.cpp
This one fails like:
/tmp/llvm/utils/release/rc2/llvm.src/test/tools/llvm-cov/showExpansions.cpp:19:15: error: expected string not found in input
// CHECK-DAG: Expansion at line [[@LINE-4]], 7 → 24
^
:1:1: note: scanning from here
warning: profile data may be out of date - object is newer
^
:1:1: note: with expression “@LINE-4” equal to “15”
warning: profile data may be out of date - object is newer
^
LLVM :: tools/llvm-cov/showHighlightedRanges.cpp
LLVM :: tools/llvm-cov/showLineExecutionCounts.cpp
LLVM :: tools/llvm-cov/showRegionMarkers.cpp
LLVM :: tools/llvm-cov/showTemplateInstantiations.cpp
LLVM :: tools/llvm-cov/universal-binary.c
LLVM :: tools/llvm-cov/warnings.h
These ^^ fail with “std::future_error / No associated state” as well.
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
These don’t confess why they failed in the log.
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostbyname_r_bad_host_name
This one fails like so:
[ RUN ] MemorySanitizer.gethostbyname_r_bad_host_name
/tmp/llvm/utils/release/rc2/llvm.src/projects/compiler-rt/lib/msan/tests/msan_test.cc:1114: Failure
Value of: result
Actual: 0x7fff577579b8
Expected: (struct hostent *)0
Which is: NULL
[ FAILED ] MemorySanitizer.gethostbyname_r_bad_host_name (160 ms)
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostbyname_r_bad_host_name
These ^^ tests fail in same fashion as above without the “with-call”.
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
MemorySanitizer-x86_64 :: Linux/obstack.cc
MemorySanitizer-x86_64 :: Linux/process_vm_readv.cc
MemorySanitizer-x86_64 :: fork.cc
MemorySanitizer-x86_64 :: iconv.cc
^^ fail with the new bash redirection alias.
Profile-x86_64 :: Linux/coverage_ctors.cpp
Profile-x86_64 :: Linux/coverage_dtor.cpp
Profile-x86_64 :: Linux/coverage_shared.test
Profile-x86_64 :: Linux/coverage_test.cpp
Profile-x86_64 :: Linux/extern_template.test
Profile-x86_64 :: Linux/instrprof-comdat.test
Profile-x86_64 :: instrprof-visibility.cpp
^^ std::future_error
SanitizerCommon-Unit :: Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
/tmp/llvm/utils/release/rc2/llvm.src/projects/compiler-rt/lib/sanitizer_common/tests/sanitizer_linux_test.cc:230: Failure
Value of: ThreadDescriptorSize()
Actual: 2288
Expected: (uptr)result
Which is: 2304
Scudo :: alignment.cpp
Scudo :: double-free.cpp
Scudo :: malloc.cpp
Scudo :: memalign.cpp
Scudo :: mismatch.cpp
Scudo :: overflow.cpp
Scudo :: preinit.cpp
Scudo :: quarantine.cpp
Scudo :: realloc.cpp
Scudo :: sized-delete.cpp
Scudo :: sizes.cpp
These ^^ fail to find libatomic when linking. This was added to libstdc++4.8 but is not present in 4.7. "Due to time constraints and an API which is not finalized, there is no libatomic supplied with GCC 4.7. " from https://gcc.gnu.org/wiki/Atomic/GCCMM
ThreadSanitizer-x86_64 :: Linux/mutex_robust.cc
ThreadSanitizer-x86_64 :: Linux/mutex_robust2.cc
These fail to find pthread_mutexattr_getrobust while linking. pthread.h on SLES11.3 defines pthread_mutexattr_getrobust and pthread_mutexattr_getrobust_np (depending on options like __USE_GNU) but libpthread contains only pthread_mutexattr_getrobust_np.
ThreadSanitizer-x86_64 :: thread_name2.cc
^^ glibc 2.11 doesn’t include ‘pthread_setname_np’.
libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp
^^ glibc doesn’t get uchar until 2.16.
libc++ :: std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp
libc++ :: std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp
^^ these tests fail the 'msg == “Unknown error -1” ’ assertion. I don’t see an obvious reason for why this would fail.
llvm.check-Phase3-Release.log (363 KB)
Re-sending this message w/compressed attachment instead.
llvm.check-Phase3-Release.log.bz2 (22.8 KB)
All good for debian8 x86_64 and MIPS/MIPSEL:
95e43919516c916b885bb791ff361ec43e111215 clang+llvm-3.9.1-rc2-mipsel-linux-gnu.tar.xz
fc5fee5b1c014e9c5886c1dd09a0a61e36904653 clang+llvm-3.9.1-rc2-mips-linux-gnu.tar.xz
1d3b3aca4141ab63bd392c0665d669abb6faccc0 clang+llvm-3.9.1-rc2-x86_64-linux-gnu-debian8.tar.xz
I'll run a few more tests for MIPSEL but I'm not expecting any problems. I'll report back if there's any test failure.
- V. Kalintiris
Re-sending this message w/compressed attachment instead.
Were these failures also present in the 3.9.0 release?
-Tom
I suspect some may have been. I was in a bit of a transition at the 3.9.0
and couldn't get a build machine working in time to provide content for the
release date.
I'm building 3.9.0 now to compare.
Looking great on Debian on all archs (except armel but this is not a recent regression).
Sylvestre