[llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here (original) (raw)

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 3 01:57:42 PST 2020


On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric <dimitry at andric.com> wrote:

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

Thanks! I've added it to the pre-release page and also to the github release.

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/locallaplacian/CMakeFiles/halidelocallaplacian.dir//common/x86halideruntime.bc.o -MF Bitcode/Benchmarks/Halide/locallaplacian/CMakeFiles/halidelocallaplacian.dir//common/x86halideruntime.bc.o.d -o Bitcode/Benchmarks/Halide/locallaplacian/CMakeFiles/halidelocallaplacian.dir//common/x86halideruntime.bc.o -c /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86halideruntime.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::uniqueptr<llvm::rawpwritestream, std::_1::defaultdeletellvm::rawpwritestream >) () #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 cc1main(llvm::ArrayRef<char const*>, char const*, void*) () #11 0x0000000001cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) () _#12 0x00000000039eb297 in void llvm::functionref<void ()>::callbackfn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::_1::basicstring<char, std::_1::chartraits, std::1::allocator >, bool) const::$1>(long) () #13 0x00000000033e406a in llvm::CrashRecoveryContext::RunSafely(llvm::functionref<void ()>) () _#14 0x00000000039ea7f0 in clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::_1::basicstring<char, std::_1::chartraits, std::1::allocator >, 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?

I haven't seen one, but I'm behind on email. Can you please file one to make sure this gets tracked?

Thanks, Hans



More information about the llvm-dev mailing list