[llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here (original) (raw)
Dimitry Andric via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 3 11:28:17 PST 2020
- Previous message: [llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here
- Next message: [llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3 Feb 2020, at 10:57, Hans Wennborg <hans at chromium.org> wrote:
On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric <dimitry at andric.com> wrote: ... 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?
Filed <https://bugs.llvm.org/show_bug.cgi?id=44763>. I didn't have a debug build of clang, so not a really informative backtrace yet.
I suppose the pre-supplied .bc files don't really get processed well by recent versions of clang. I hope that others can reproduce this.
-Dimitry
-------------- 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/llvm-dev/attachments/20200203/72038c3a/attachment.sig>
- Previous message: [llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here
- Next message: [llvm-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]