[libcxx-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via libcxx-dev]

On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote:
> 
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11 (I will post i386 results as they become
available):

  Expected Passes    : 67894
  Expected Failures  : 268
  Unsupported Tests  : 4653
  Unexpected Passes  : 5
  Unexpected Failures: 541
  Individual Timeouts: 18

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++ -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -MF Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d -o Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -c /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x000000010000000f in ?? ()
(gdb) bt
#0  0x000000010000000f in ?? ()
#1  0x00000000028ca9c0 in llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2  0x0000000002e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3  0x0000000002e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4  0x0000000002e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5  0x00000000035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) ()
#6  0x0000000003c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7  0x0000000003b7abca in clang::FrontendAction::Execute() ()
#8  0x0000000003aea761 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9  0x0000000003c12905 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x0000000001cbaf0e in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#11 0x0000000001cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) ()
#12 0x00000000039eb297 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const::$_1>(long) ()
#13 0x00000000033e406a in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) ()
#14 0x00000000039ea7f0 in clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const ()
#15 0x00000000039bfc5c in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const ()
#16 0x00000000039c01ac in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) const ()
#17 0x00000000039d336c in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) ()
#18 0x0000000001cb884f in main ()

Looks like the bitcode compilation path is totally busted?  Anybody know
an open bug for this?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-clang-1.diff
Type: application/octet-stream
Size: 447 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200131/93e7f485/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-compiler-rt-1.diff
Type: application/octet-stream
Size: 890 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200131/93e7f485/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-test-suite-1.diff
Type: application/octet-stream
Size: 552 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200131/93e7f485/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200131/93e7f485/attachment.sig>