Setting opt-level = 3 will cause stage1-rustc to segfault on Linux

[kennytm]

Stack trace:

#0  0x00007f9fc5fe6a11 in llvm::scc_iterator<llvm::CallGraph*, llvm::GraphTraits<llvm::CallGraph*> >::DFSVisitOne(llvm::CallGraphNode*) ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#0  0x00007f9fc5fe6a11 in llvm::scc_iterator<llvm::CallGraph*, llvm::GraphTraits<llvm::CallGraph*> >::DFSVisitOne(llvm::CallGraphNode*) ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#1  0x00007f9fc6f295b1 in (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#2  0x00007f9fc7289f0c in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#3  0x00007f9fc720c829 in LLVMRunPassManager ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#4  0x00007f9fc5681fe7 in rustc_codegen_llvm::back::write::execute_work_item::hfd3cb98239864c6b ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#5  0x00007f9fc56343a3 in std::sys_common::backtrace::__rust_begin_short_backtrace::h8c37409cc6efa4b9 ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#6  0x00007f9fc5658096 in std::panicking::try::do_call::h3fbe882ce88a0178 ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#7  0x00007f9fcfc0942a in __rust_maybe_catch_panic ()
    at libpanic_unwind/lib.rs:106
#8  0x00007f9fc5641ad1 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hcd99e38bedf3313c ()
   from ./checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#9  0x00007f9fcfbc13bb in call_once<(),()> ()
    at /checkout/src/liballoc/boxed.rs:650
#10 std::sys_common::thread::start_thread::hf91e8d5f6a6b3cf0 ()
    at libstd/sys_common/thread.rs:24
#11 0x00007f9fcfbc6bf6 in std::sys::unix::thread::Thread::new::thread_start::h3a956f4a27a51528 () at libstd/sys/unix/thread.rs:90
#12 0x00007f9fc9d196ba in ?? ()
#13 0x0000000000000000 in ?? ()

Examples:

• rustc: Tweak expansion of #[proc_macro] for 2018 #52326 (comment)
• Remove most of PartialEq and Hash impls from AST and HIR structures #51829 (comment)

[kennytm]

In #52326 (comment) we build with LLVM assertions enabled, but there is no messages from the log, meaning the segfault is not caused by broken assertions.

[alexcrichton]

When setting opt-level=3 I believe that also changes the C/C++ code's optimization level, so this may be a but in clang's O3 optimization passes as well (and may in theory be fixable by compiling C++ code with O2)

[mati865]

When setting opt-level=3 I believe that also changes the C/C++ code's optimization level

I inspected generated CMake files and LLVM is built with -O3 nowadays but Rust is still using opt-level=2.

How can I see if reapplying opt-level=3 works without possibly breaking CI?

[ghost]

https://github.com/rust-lang/rust/blob/master/Cargo.toml#L33

mentions LLVM7.0. Rust recently update to LLVM9.0.
So is this still an issue?