Clang 8.0.0 shipped with FreeBSD 11.3 seems to segfault when compiling certain ports with -march=bonnel (CPUTYPE=atom specified in /etc/make.conf). Here is a backtrace from gdb: #0 0x0000000001cc65d3 in (anonymous namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&, llvm::raw_ostream&, llvm::SmallVectorImpl<llvm::MCFixup>&, llvm::MCSubtargetInfo const&) const () #1 0x0000000002045312 in llvm::MCELFStreamer::EmitInstToData(llvm::MCInst const&, llvm::MCSubtargetInfo const&) () #2 0x00000000020990c1 in llvm::MCObjectStreamer::EmitInstruction(llvm::MCInst const&, llvm::MCSubtargetInfo const&, bool) () #3 0x0000000001a4a35e in llvm::X86AsmPrinter::EmitInstruction(llvm::MachineInstr const*) () #4 0x0000000002ac10c5 in llvm::AsmPrinter::EmitFunctionBody() () #5 0x00000000018c65e8 in llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) () #6 0x0000000002ad5d6a in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () #7 0x00000000025759dd in llvm::FPPassManager::runOnFunction(llvm::Function&) () #8 0x0000000002575ca3 in llvm::FPPassManager::runOnModule(llvm::Module&) () #9 0x000000000257607a in llvm::legacy::PassManagerImpl::run(llvm::Module&) () #10 0x000000000043250b 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> >) () #11 0x000000000042da27 in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () #12 0x00000000008799c3 in clang::ParseAST(clang::Sema&, bool, bool) () #13 0x0000000000870f05 in clang::FrontendAction::Execute() () #14 0x0000000000dfc188 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () #15 0x000000000040ec5a in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) () #16 0x000000000040095c in cc1_main (Argv=..., Argv0=0x7fffffffdcf8 "/usr/bin/cc", MainAddr=0x409e40 <GetExecutablePath(char const*, bool)>) at /usr/src/contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:219 #17 0x000000000040c816 in ExecuteCC1Tool (argv=..., Tool=...) at /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:310 #18 main (argc_=<optimized out>, argv_=0x7fffffffd610) at /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 Attached are the debug files clang dumped in /tmp.
Created attachment 207950 [details] Preprocessed C file and script
A commit references this bug: Author: dim Date: Mon Sep 30 19:24:21 UTC 2019 New revision: 352915 URL: https://svnweb.freebsd.org/changeset/base/352915 Log: Pull in r357528 from upstream llvm trunk (by Craig Topper): [X86] Check MI.isConvertibleTo3Addr() before calling convertToThreeAddress in X86FixupLEAs. X86FixupLEAs just assumes convertToThreeAddress will return nullptr for any instruction that isn't convertible. But the code in convertToThreeAddress for X86 assumes that any instruction coming in has at least 2 operands and that the second one is a register. But those properties aren't guaranteed of all instructions. We should check the instruction property first. Pull in r365720 from upstream llvm trunk (by Craig Topper): [X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass. We use the functions that convert to three address to do the conversion, but changing an 8 or 16 bit will cause it to create a virtual register. This can't be done after register allocation where this pass runs. I've switched the pass completely to a white list of instructions that can be converted to LEA instead of a blacklist that was incorrect. This will avoid surprises if we enhance the three address conversion function to include additional instructions in the future. Fixes PR42565. This should fix assertions/segfaults when compiling certain ports with CPUTYPE=atom. PR: 240928 MFC after: 3 days Changes: head/contrib/llvm/lib/Target/X86/X86FixupLEAs.cpp
Thanks Dimitry ^Triage: Leave mfc-* flags open until merge. @Dimitry, if this needs to be merged to releng/12.1 for 12.1-RELEASE, please add bug 240700 to this issues "Blocks" field
A commit references this bug: Author: dim Date: Thu Oct 3 06:08:05 UTC 2019 New revision: 353031 URL: https://svnweb.freebsd.org/changeset/base/353031 Log: MFC r352915: Pull in r357528 from upstream llvm trunk (by Craig Topper): [X86] Check MI.isConvertibleTo3Addr() before calling convertToThreeAddress in X86FixupLEAs. X86FixupLEAs just assumes convertToThreeAddress will return nullptr for any instruction that isn't convertible. But the code in convertToThreeAddress for X86 assumes that any instruction coming in has at least 2 operands and that the second one is a register. But those properties aren't guaranteed of all instructions. We should check the instruction property first. Pull in r365720 from upstream llvm trunk (by Craig Topper): [X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass. We use the functions that convert to three address to do the conversion, but changing an 8 or 16 bit will cause it to create a virtual register. This can't be done after register allocation where this pass runs. I've switched the pass completely to a white list of instructions that can be converted to LEA instead of a blacklist that was incorrect. This will avoid surprises if we enhance the three address conversion function to include additional instructions in the future. Fixes PR42565. This should fix assertions/segfaults when compiling certain ports with CPUTYPE=atom. PR: 240928 Changes: _U stable/11/ stable/11/contrib/llvm/lib/Target/X86/X86FixupLEAs.cpp _U stable/12/ stable/12/contrib/llvm/lib/Target/X86/X86FixupLEAs.cpp
A commit references this bug: Author: dim Date: Thu Oct 3 16:22:56 UTC 2019 New revision: 353053 URL: https://svnweb.freebsd.org/changeset/base/353053 Log: Merge r353031 from stable/12: Pull in r357528 from upstream llvm trunk (by Craig Topper): [X86] Check MI.isConvertibleTo3Addr() before calling convertToThreeAddress in X86FixupLEAs. X86FixupLEAs just assumes convertToThreeAddress will return nullptr for any instruction that isn't convertible. But the code in convertToThreeAddress for X86 assumes that any instruction coming in has at least 2 operands and that the second one is a register. But those properties aren't guaranteed of all instructions. We should check the instruction property first. Pull in r365720 from upstream llvm trunk (by Craig Topper): [X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass. We use the functions that convert to three address to do the conversion, but changing an 8 or 16 bit will cause it to create a virtual register. This can't be done after register allocation where this pass runs. I've switched the pass completely to a white list of instructions that can be converted to LEA instead of a blacklist that was incorrect. This will avoid surprises if we enhance the three address conversion function to include additional instructions in the future. Fixes PR42565. This should fix assertions/segfaults when compiling certain ports with CPUTYPE=atom. Approved by: re (kib) PR: 240928 Changes: _U releng/12.1/ releng/12.1/contrib/llvm/lib/Target/X86/X86FixupLEAs.cpp