Brian Cain via llvm-dev
2016-Dec-04 15:38 UTC
[llvm-dev] [Release-testers] 3.9.1-rc2 is ready for testing
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
^
<stdin>:1:1: note: scanning from here
warning: profile data may be out of date - object is newer
^
<stdin>: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.
On Fri, Dec 2, 2016 at 6:37 PM, Brian Cain <brian.cain at gmail.com>
wrote:
>
>
> On Thu, Dec 1, 2016 at 9:53 PM, Tom Stellard via Release-testers <
> release-testers at lists.llvm.org> wrote:
>
>> 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.
>>
>>
>>
> SLES11SP3 fails during tests.
>
> [ 92%] Building CXX object unittests/MC/CMakeFiles/MCTests.dir/
> StringTableBuilderTest.cpp.o
>
/tmp/llvm/utils/release/rc2/llvm.src/unittests/ExecutionEngine/Orc/RPCUtilsTest.cpp:37:27:
> error: no member named 'yield' in namespace
'std::this_thread'
> std::this_thread::yield();
> ~~~~~~~~~~~~~~~~~~^
> [ 92%] Building CXX object unittests/MC/CMakeFiles/
> MCTests.dir/TargetRegistry.cpp.o
> 1 error generated.
>
>
>
> It looks like it's only present when _GLIBCXX_USE_SCHED_YIELD.
I'll see
> if I can figure out why it would be packaged this way unless anyone knows
> off the top of their head.
>
--
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/8770fdc7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.check-Phase3-Release.log
Type: text/x-log
Size: 372087 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/8770fdc7/attachment-0001.bin>
Brian Cain via llvm-dev
2016-Dec-04 18:07 UTC
[llvm-dev] [Release-testers] 3.9.1-rc2 is ready for testing
Re-sending this message w/compressed attachment instead. On Sun, Dec 4, 2016 at 9:38 AM, Brian Cain <brian.cain at gmail.com> wrote:> 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 > ^ > <stdin>:1:1: note: scanning from here > warning: profile data may be out of date - object is newer > ^ > <stdin>: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. > >-- -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/58c874e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.check-Phase3-Release.log.bz2 Type: application/x-bzip2 Size: 23334 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/58c874e3/attachment.bin>
Tom Stellard via llvm-dev
2016-Dec-06 00:07 UTC
[llvm-dev] [Release-testers] 3.9.1-rc2 is ready for testing
On Sun, Dec 04, 2016 at 12:07:05PM -0600, Brian Cain wrote:> Re-sending this message w/compressed attachment instead. >Were these failures also present in the 3.9.0 release? -Tom> On Sun, Dec 4, 2016 at 9:38 AM, Brian Cain <brian.cain at gmail.com> wrote: > > > 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 > > ^ > > <stdin>:1:1: note: scanning from here > > warning: profile data may be out of date - object is newer > > ^ > > <stdin>: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. > > > > > -- > -Brian