Compiling LLVM 14.x with `clang-cl` and `/arch:AVX` or `-march=sandybridge` crashes. #54645

tru · 2022-03-30T15:09:35Z

Setup:

Build clang and lld with MSVC.
configure LLVM with: cmake -GNinja -DLLVM_ENABLE_LTO=Thin -DCMAKE_CXX_FLAGS="/arch:AVX" -DCMAKE_C_FLAGS="/arch:AVX" -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_LINKER=lld-link.exe ..\llvm
Build llvm-profdata (it probably happens with other binaries - but this is pretty fast and easy to reproduce it with)

crash in:

17:01:04  #0 0x00007ff612ca30a1 llvm::SelectionDAG::createOperands(class llvm::SDNode *, class llvm::ArrayRef<class llvm::SDValue>) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:11084:0
17:01:04  #1 0x00007ff612cbbf07 llvm::SelectionDAG::getNode(unsigned int, class llvm::SDLoc const &, struct llvm::EVT, class llvm::ArrayRef<class llvm::SDValue>, struct llvm::SDNodeFlags) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:8420:0
17:01:04  #2 0x00007ff612cbbca2 llvm::SelectionDAG::getNode(unsigned int, class llvm::SDLoc const &, struct llvm::EVT, class llvm::ArrayRef<class llvm::SDValue>) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:8358:0
17:01:04  #3 0x00007ff612b373ce lowerV8I16Shuffle C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:15804:0
17:01:04  #4 0x00007ff612b39862 lowerVECTOR_SHUFFLE C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:19171:0
17:01:04  #5 0x00007ff612a6bc27 llvm::X86TargetLowering::LowerOperation(class llvm::SDValue, class llvm::SelectionDAG &) const C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:31599:0
17:01:04  #6 0x00007ff612e0b294 `anonymous namespace'::SelectionDAGLegalize::LegalizeOp C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp:1281:0
17:01:04  #7 0x00007ff612e09413 llvm::SelectionDAG::Legalize(void) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp:4995:0
17:01:04  #8 0x00007ff612d0feb9 llvm::SelectionDAGISel::CodeGenAndEmitDAG(void) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:933:0
17:01:04  #9 0x00007ff612d14acd llvm::SelectionDAGISel::SelectAllBasicBlocks(class llvm::Function const &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:1631:0
17:01:04 #10 0x00007ff612d1b404 llvm::SelectionDAGISel::runOnMachineFunction(class llvm::MachineFunction &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:511:0
17:01:04 #11 0x00007ff612978a1d `anonymous namespace'::X86DAGToDAGISel::runOnMachineFunction C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelDAGToDAG.cpp:195:0
17:01:04 #12 0x00007ff612f19321 llvm::MachineFunctionPass::runOnFunction(class llvm::Function &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\MachineFunctionPass.cpp:72:0
17:01:04 #13 0x00007ff613cbf12b llvm::FPPassManager::runOnFunction(class llvm::Function &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1434:0
17:01:04 #14 0x00007ff613cbf373 llvm::FPPassManager::runOnModule(class llvm::Module &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1479:0
17:01:04 #15 0x00007ff613cbf5b8 `anonymous namespace'::MPPassManager::runOnModule C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1549:0
17:01:04 #16 0x00007ff613cbee20 llvm::legacy::PassManager::run(class llvm::Module &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1676:0
17:01:04 #17 0x00007ff612ee782e codegen C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTOBackend.cpp:430:0
17:01:04 #18 0x00007ff612ee62e5 <lambda_e0845f8b0ff363d6d03d2cd977f2ce79>::operator() C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTOBackend.cpp:598:0
17:01:04 #19 0x00007ff612eeb90a llvm::lto::thinBackend(struct llvm::lto::Config const &, unsigned int, class std::function<(unsigned int)>, class llvm::Module &, class llvm::ModuleSummaryIndex const &, class llvm::StringMap<class std::unordered_set<unsigned __int64, struct std::hash<unsigned __int64>, struct std::equal_to<unsigned __int64>, class std::allocator<unsigned __int64>>, class llvm::MallocAllocator> const &, class llvm::DenseMap<unsigned __int64, class llvm::GlobalValueSummary *, struct llvm::DenseMapInfo<unsigned __int64, void>, struct llvm::detail::DenseMapPair<unsigned __int64, class llvm::GlobalValueSummary *>> const &, class llvm::MapVector<class llvm::StringRef, class llvm::BitcodeModule, class llvm::DenseMap<class llvm::StringRef, unsigned int, struct llvm::DenseMapInfo<class llvm::StringRef, void>, struct llvm::detail::DenseMapPair<class llvm::StringRef, unsigned int>>, class std::vector<struct std::pair<class llvm::StringRef, class llvm::BitcodeModule>, class std::allocator<struct std::pair<class llvm::StringRef, class llvm::BitcodeModule>>>> *, class std::vector<unsigned char, class std::allocator<unsigned char>> const &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTOBackend.cpp:668:0
17:01:04 #20 0x00007ff612ed6ae7 <lambda_51cf04bbbb9cfc9263f3cfeece7282d7>::operator() C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTO.cpp:1225:0
17:01:04 #21 0x00007ff612ee1727 `anonymous namespace'::InProcessThinBackend::runThinLTOBackendThread C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTO.cpp:1248:0
17:01:04 #22 0x00007ff612ed6520 <lambda_2762ba73044a280da963d9912b490b63>::operator() C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\LTO\LTO.cpp:1277:0
17:01:04 #23 0x00007ff612ed862a std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,<lambda_2762ba73044a280da963d9912b490b63>,llvm::BitcodeModule &,std::reference_wrapper<llvm::ModuleSummaryIndex>,std::reference_wrapper<llvm::StringMap<std::unordered_set<unsigned __int64,std::hash<unsigned __int64>,std::equal_to<unsigned __int64>,std::allocator<unsigned __int64> >,llvm::MallocAllocator> const >,std::reference_wrapper<llvm::DenseSet<llvm::ValueInfo,llvm::DenseMapInfo<llvm::ValueInfo,void> > const >,std::reference_wrapper<std::map<unsigned __int64,enum llvm::GlobalValue::LinkageTypes,std::less<unsigned __int64>,std::allocator<std::pair<unsigned __int64 const ,enum llvm::GlobalValue::LinkageTypes> > > const >,std::reference_wrapper<llvm::DenseMap<unsigned __int64,llvm::GlobalValueSummary *,llvm::DenseMapInfo<unsigned __int64,void>,llvm::detail::DenseMapPair<unsigned __int64,llvm::GlobalValueSummary *> > const >,std::reference_wrapper<llvm::MapVector<llvm::StringRef,llvm::BitcodeModule,llvm::DenseMap<llvm::StringRef,unsigned int,llvm::DenseMapInfo<llvm::StringRef,void>,llvm::detail::DenseMapPair<llvm::StringRef,unsigned int> >,std::vector<std::pair<llvm::StringRef,llvm::BitcodeModule>,std::allocator<std::pair<llvm::StringRef,llvm::BitcodeModule> > > > > >,void>::_Do_call C:\.nuget\dd\vs2019_buildtools.16.11.9\tools\VC\Tools\MSVC\14.29.30133\include\functional:921:0
17:01:04 #24 0x00007ff6128781fc std::_Func_impl_no_alloc<class <lambda_3f890a8f4379cabfb886f101ac7ee7cd>, void>::_Do_call(void) C:\.nuget\dd\vs2019_buildtools.16.11.9\tools\VC\Tools\MSVC\14.29.30133\include\functional:920:0
17:01:04 #25 0x00007ff613ee1a8f <lambda_647dacfb2f54ceb9a051a40a222b4ef4>::operator() C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Support\ThreadPool.cpp:64:0
17:01:04 #26 0x00007ff613ee143e llvm::thread::ThreadProxy<std::tuple<<lambda_647dacfb2f54ceb9a051a40a222b4ef4> > > C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\include\llvm\Support\thread.h:70:0
17:01:04 #27 0x00007ff613eaeb04 thread_start<unsigned int (__cdecl*)(void *),1> minkernel\crts\ucrt\src\appcrt\startup\thread.cpp:97:0
17:01:04 #28 0x00007ffb51707034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034)
17:01:04 #29 0x00007ffb52c42651 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x52651)

I have also tested with -march=sandbridge which equals crash and -march=skylake which works.

The text was updated successfully, but these errors were encountered:

llvmbot · 2022-03-30T15:10:00Z

@llvm/issue-subscribers-clang-codegen

llvmbot · 2022-03-30T15:10:30Z

@llvm/issue-subscribers-clang-driver

tru · 2022-03-30T15:42:48Z

Turning off LTO and we get a specific file that crashes:

17:38:40 FAILED: lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/BitcodeReader.cpp.obj 
17:38:40 C:\code\llvm\llvm.packageci\build\stage0\bin\clang-cl.exe  /nologo -TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:\code\llvm\llvm.packageci\build\final\lib\Bitcode\Reader -IC:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Bitcode\Reader -IC:\code\llvm\llvm.packageci\build\final\include -IC:\code\llvm\llvm.packageci\externals\llvm-project\llvm\include /GS- /D_ITERATOR_DEBUG_LEVEL=0 -fstrict-aliasing -Wno-backend-plugin -march=sandybridge /Zc:inline /Zc:__cplusplus /Zi -gcodeview-ghash /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /bigobj /W4  -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation /Gw /MT /O2 /Ob2 /DNDEBUG  /EHs-c- /GR- -std:c++14 /showIncludes /Folib\Bitcode\Reader\CMakeFiles\LLVMBitReader.dir\BitcodeReader.cpp.obj /Fdlib\Bitcode\Reader\CMakeFiles\LLVMBitReader.dir\LLVMBitReader.pdb -c -- C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Bitcode\Reader\BitcodeReader.cpp
17:38:40 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
17:38:40 Stack dump:
17:38:40 1.	<eof> parser at end of file
17:38:40 2.	Code generation
17:38:40 3.	Running pass 'Function Pass Manager' on module 'C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Bitcode\Reader\BitcodeReader.cpp'.
17:38:40 4.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@"??$?0PEA_KX@?$SmallVector@G$0BA@@llvm@@QEAA@PEA_K0@Z"'
17:38:40  #0 0x00007ff66cb54851 llvm::SelectionDAG::createOperands(class llvm::SDNode *, class llvm::ArrayRef<class llvm::SDValue>) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:11084:0
17:38:40  #1 0x00007ff66cb6d3f7 llvm::SelectionDAG::getNode(unsigned int, class llvm::SDLoc const &, struct llvm::EVT, class llvm::ArrayRef<class llvm::SDValue>, struct llvm::SDNodeFlags) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:8420:0
17:38:40  #2 0x00007ff66cb6d192 llvm::SelectionDAG::getNode(unsigned int, class llvm::SDLoc const &, struct llvm::EVT, class llvm::ArrayRef<class llvm::SDValue>) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAG.cpp:8358:0
17:38:40  #3 0x00007ff66b6112ce lowerV8I16Shuffle C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:15804:0
17:38:40  #4 0x00007ff66b613762 lowerVECTOR_SHUFFLE C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:19171:0
17:38:40  #5 0x00007ff66b546e57 llvm::X86TargetLowering::LowerOperation(class llvm::SDValue, class llvm::SelectionDAG &) const C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelLowering.cpp:31599:0
17:38:40  #6 0x00007ff66ccb83e4 `anonymous namespace'::SelectionDAGLegalize::LegalizeOp C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp:1281:0
17:38:40  #7 0x00007ff66ccb64a3 llvm::SelectionDAG::Legalize(void) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp:4995:0
17:38:40  #8 0x00007ff66cbbf729 llvm::SelectionDAGISel::CodeGenAndEmitDAG(void) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:933:0
17:38:40  #9 0x00007ff66cbc43cd llvm::SelectionDAGISel::SelectAllBasicBlocks(class llvm::Function const &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:1631:0
17:38:40 #10 0x00007ff66cbcad24 llvm::SelectionDAGISel::runOnMachineFunction(class llvm::MachineFunction &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\SelectionDAG\SelectionDAGISel.cpp:511:0
17:38:40 #11 0x00007ff66b44f27d `anonymous namespace'::X86DAGToDAGISel::runOnMachineFunction C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Target\X86\X86ISelDAGToDAG.cpp:195:0
17:38:40 #12 0x00007ff66b8ab3d1 llvm::MachineFunctionPass::runOnFunction(class llvm::Function &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\CodeGen\MachineFunctionPass.cpp:72:0
17:38:40 #13 0x00007ff66bb53eeb llvm::FPPassManager::runOnFunction(class llvm::Function &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1434:0
17:38:40 #14 0x00007ff66bb54133 llvm::FPPassManager::runOnModule(class llvm::Module &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1479:0
17:38:40 #15 0x00007ff66bb54378 `anonymous namespace'::MPPassManager::runOnModule C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1549:0
17:38:40 #16 0x00007ff66bb53be0 llvm::legacy::PassManager::run(class llvm::Module &) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1676:0
17:38:40 #17 0x00007ff66c381555 `anonymous namespace'::EmitAssemblyHelper::EmitAssembly C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\CodeGen\BackendUtil.cpp:1565:0
17:38:40 #18 0x00007ff66c38306a clang::EmitBackendOutput(class clang::DiagnosticsEngine &, class clang::HeaderSearchOptions const &, class clang::CodeGenOptions const &, class clang::TargetOptions const &, class clang::LangOptions const &, class llvm::StringRef, class llvm::Module *, enum clang::BackendAction, class std::unique_ptr<class llvm::raw_pwrite_stream, struct std::default_delete<class llvm::raw_pwrite_stream>>) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\CodeGen\BackendUtil.cpp:1732:0
17:38:40 #19 0x00007ff66e2c19da clang::BackendConsumer::HandleTranslationUnit(class clang::ASTContext &) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\CodeGen\CodeGenAction.cpp:374:0
17:38:40 #20 0x00007ff66d405984 clang::ParseAST(class clang::Sema &, bool, bool) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Parse\ParseAST.cpp:178:0
17:38:40 #21 0x00007ff66c9066f7 clang::ASTFrontendAction::ExecuteAction(void) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Frontend\FrontendAction.cpp:1074:0
17:38:40 #22 0x00007ff66e2bfbaa clang::CodeGenAction::ExecuteAction(void) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\CodeGen\CodeGenAction.cpp:1181:0
17:38:40 #23 0x00007ff66c906172 clang::FrontendAction::Execute(void) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Frontend\FrontendAction.cpp:971:0
17:38:40 #24 0x00007ff66c8d0eef clang::CompilerInstance::ExecuteAction(class clang::FrontendAction &) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Frontend\CompilerInstance.cpp:1036:0
17:38:40 #25 0x00007ff66c96cbb9 clang::ExecuteCompilerInvocation(class clang::CompilerInstance *) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\FrontendTool\ExecuteCompilerInvocation.cpp:263:0
17:38:40 #26 0x00007ff66b402376 cc1_main(class llvm::ArrayRef<char const *>, char const *, void *) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\tools\driver\cc1_main.cpp:248:0
17:38:40 #27 0x00007ff66b3fd3b4 ExecuteCC1Tool C:\code\llvm\llvm.packageci\externals\llvm-project\clang\tools\driver\driver.cpp:317:0
17:38:40 #28 0x00007ff66c7f09e7 llvm::function_ref<void __cdecl(void)>::callback_fn<<lambda_25c96514421f9d21a88a4b637eac86f0> > C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\include\llvm\ADT\STLFunctionalExtras.h:45:0
17:38:40 #29 0x00007ff66c0c39ef llvm::CrashRecoveryContext::RunSafely(class llvm::function_ref<(void)>) C:\code\llvm\llvm.packageci\externals\llvm-project\llvm\lib\Support\CrashRecoveryContext.cpp:237:0
17:38:40 #30 0x00007ff66c7f0fb0 clang::driver::CC1Command::Execute(class llvm::ArrayRef<class llvm::Optional<class llvm::StringRef>>, class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> *, bool *) const C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Driver\Job.cpp:407:0
17:38:40 #31 0x00007ff66c76f802 clang::driver::Compilation::ExecuteCommand(class clang::driver::Command const &, class clang::driver::Command const *&) const C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Driver\Compilation.cpp:197:0
17:38:40 #32 0x00007ff66c76fb4d clang::driver::Compilation::ExecuteJobs(class clang::driver::JobList const &, class llvm::SmallVectorImpl<struct std::pair<int, class clang::driver::Command const *>> &) const C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Driver\Compilation.cpp:249:0
17:38:40 #33 0x00007ff66c757716 clang::driver::Driver::ExecuteCompilation(class clang::driver::Compilation &, class llvm::SmallVectorImpl<struct std::pair<int, class clang::driver::Command const *>> &) C:\code\llvm\llvm.packageci\externals\llvm-project\clang\lib\Driver\Driver.cpp:1617:0
17:38:40 #34 0x00007ff66b3ff641 main C:\code\llvm\llvm.packageci\externals\llvm-project\clang\tools\driver\driver.cpp:492:0
17:38:40 #35 0x00007ff66e0571a0 __scrt_common_main_seh d:\a01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0
17:38:40 #36 0x00007ffb51707034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034)
17:38:40 #37 0x00007ffb52c42651 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x52651)

tru · 2022-03-30T15:43:12Z

I'll try to reduce it tomorrow.

tru · 2022-03-31T12:25:57Z

Ok this issue is a bit stranger than I originally thought. @sylvain-audi was able to reduce the test case to the following:

inline void*  operator new(size_t _Size, void* _Where) {
  return _Where;
}
template <typename T>
struct SmallVector {
  T Items[16];
  T *Begin = nullptr;
  unsigned Size = 0;
  template <class _T2>
  void _Construct_in_place3(T& _Obj, _T2&& val) {
    new (&_Obj) T(val);
  }
  template <typename ItTy>
  SmallVector(ItTy S, ItTy E)
  : Begin(&this->Items[0]){
    T* _Last = this->Begin;
    for (; S != E; ++S) {
        this->_Construct_in_place3(*_Last, *S);
        _Last++;
    }
  }
};
bool ExternalTest();
void MainFunc() {
  unsigned long long Values[] = { 1 };
  SmallVector<unsigned long long> Record{ Values, Values + 1 };
  if (ExternalTest()) {
    SmallVector<unsigned short> Elts2(Record.Items, Record.Items + Record.Size);
  }
}

This doesn't trigger a crash on Linux with clang - but it happens on Windows. But ONLY if the clang in question is built with MSVC and /arch:AVX - but it reproduced consistently - so I was able to bisect it to this commit: 55e4cd8 by @RKSimon

@RKSimon any idea why this commit could lead to bad things happening in MSVC?

I have a case where it reproduces 100% so if you need me to extract anymore data from it I can.

tru · 2022-03-31T12:40:59Z

Can now confirm that reverting this commit from release/14.x fixes the issue.

RKSimon · 2022-03-31T13:54:32Z

I have no good ideas tbh - what machine are you running it on?

One (very weak) hunch - in the patch could you try replacing the DWordClearOps variable SmallVector<SDValue> with SmallVector<SDValue, 4>? We haven't had the default size code for long so it might have been something in that?

RKSimon · 2022-03-31T13:56:20Z

Also, can you tell if its an non-aligned memory access? illegal instruction?

tru · 2022-03-31T14:12:16Z

Your hunch was correct

-      SmallVector<SDValue> DWordClearOps(4, DAG.getConstant(0, DL, MVT::i32));
+      SmallVector<SDValue, 4> DWordClearOps(4, DAG.getConstant(0, DL, MVT::i32));

This makes the crash go away.

RKSimon · 2022-03-31T14:53:45Z

CCing @silvasean who added the SmallVector<T> support

davidbolvansky · 2022-03-31T15:11:43Z

Which version of MSVC?

tru · 2022-03-31T15:26:35Z

I tested both 2019 16.10.11 and 2022 17.1.0.

silvasean · 2022-03-31T17:04:22Z

SmallVector<T> is just an alias for SmallVector<T, N> where N is an internally computed number. I wonder if the crash can be reproduced with SmallVector<T, N> where N is explicitly written with the same value internally computed by SmallVector<T>, or whether things are somehow getting messed up by the automatic inference of N. You can get the inferred number by printing out CalculateSmallVectorDefaultInlinedElements<T>::value.

tru · 2022-03-31T17:07:22Z

I'll give this a try tomorrow.

RKSimon · 2022-03-31T17:11:23Z

Do we want to propose the SmallVector<SDValue, 4> fix for trunk and a 14.x cherry-pick?

tru · 2022-03-31T17:14:47Z

I think we need a fix for 14.0.1 at least. But I'll defer to you guys what the easiest fix is.

silvasean · 2022-03-31T17:15:35Z

Also, I'll mention that CalculateSmallVectorDefaultInlinedElements<T>::value depends on sizeof(T), so it can be different for 32 vs 64 bit hosts, ILP64 vs LP64, asserts vs no-asserts, debug vs release, etc.

tru · 2022-04-01T07:44:32Z

I printed the value from CalculateSmallVectorDefaultInlinedElements<T>::value and it's 3, I am guessing this leads to some kind of alignment error? As expected SmallVector<SDValue, 3> also crashes. This is when MSVC has the argument /arch:AVX on the command line.

When compiling without /arch:AVX the value is still 3 so I am guessing this is a problem when the vector is a odd number and the AVX lowering in MSVC still tries to make magic with it? Sorry this is a bit over my head. Let me know if I can provide any more information.

Are we using SmallVector with the default value in many places? Then I think we need a fix for CalculateSmallVectorDefaultInlinedElements - otherwise we can probably just roll back this one.

joker-eph · 2022-04-01T08:00:33Z

This could very well be an issue with alignment indeed, but that may be a bug in MSVC. It seems worth reporting the reduced test case to Microsoft. Does it reproduce with the most recent MSVC available?

I don't think a fix in CalculateSmallVectorDefaultInlinedElements is doable unless we really know what the issue is: if this is a vectorizer issue then it is likely highly dependent on the exact code pattern involved.

tru · 2022-04-05T09:58:35Z

Ok figured out how to catch this in the debugger - it crashes here:

if (Ops[I].Val.getValueType() != MVT::Other)

The actual crash is:

Exception thrown at 0x00007FF6D77A71F9 in clang-cl.exe: 0xC0000005: Access violation reading location 0x0000019935EF9228.

Dissembling this part shows this (sorry for the screenshot - but I couldn't figure out how to copy and paste from the disasm view in vscode):

tstellar · 2022-04-05T21:09:54Z

/pull-request llvmbot#144

Do we want to merge this to the release/14.x branch or are we waiting for a better fix?

dexonsmith · 2022-04-06T00:03:01Z

/pull-request llvmbot#144

Do we want to merge this to the release/14.x branch or are we waiting for a better fix?

The current fix LGTM for release branch. I think this particular code should have an explicit small size anyway since it's using fixed-size data.

I think the ongoing discussion is just to figure out why it's necessary, to understand what issues might be buried elsewhere.

RKSimon · 2022-04-06T10:45:39Z

If at all possible it'd be great to see msvc /AVX and /AVX2 2-stage buildbots added so that we can start tracking this.

@sstamenova @rnk Are either of you to add additional bots?

…to avoid MSVC AVX alignment bug As discussed on Issue llvm#54645 - building llc with /AVX can result in incorrectly aligned structs (cherry picked from commit cb5c4a5)

sstamenova · 2022-04-08T17:09:01Z

If at all possible it'd be great to see msvc /AVX and /AVX2 2-stage buildbots added so that we can start tracking this.

@sstamenova @rnk Are either of you to add additional bots?

I can't speak for Reid, but we're not able to right now. We're toying with the idea of maybe adding another mlir bot, but that's unlikely as well. I'll keep it in mind in case we get an opportunity, but I think it unlikely.

tstellar · 2022-04-11T23:43:30Z

Merged: ec13fed

davidbolvansky · 2022-04-12T08:46:12Z

Did somebody find a root cause? If not, then this issue should be still in open state, @tstellar .

RKSimon · 2022-04-12T08:49:08Z

Alternatively we prevent MSVC /arch:AVX builds through cmake.

tru · 2022-04-12T10:23:13Z

Maybe we should at least warn it's not a tested setup.

davidbolvansky · 2022-04-12T10:35:23Z

But there are maaany possible setups which are not tested. Reverse it?

Maybe there should be a list of “tested” setups (configurations) and anything else is possibly broken and may not work.

tru · 2022-04-12T12:27:17Z

I think that's a bigger discussion - there is probably a lot of people building "unsupported" configurations. I think it makes sense to give warnings when people try to do a configuration that is known to have problems. Just listing and detecting the "supported" configurations is still a huge list.

I suggest we detect MSVC + /arch:AVX and say This configuration is unsupported and known to have caused problems. If we implement it generic enough people can add more known broken configurations to that list when they are detected.

tstellar · 2022-04-13T23:35:20Z

I'm removing the Release Milestone, since we've already merged a fix to the release branch and there still seems to be an outstanding issue in main.

RKSimon · 2022-04-14T09:09:01Z

Would we be better off splitting this into new tickets and resolving this one?

cmake warning for /AVX (and /AVX2?) builds
MSVC crash when built with /AVX - assuming we can provide a self contained test case

tru · 2022-04-14T10:23:42Z

I posted a diff for the CMake warning here: https://reviews.llvm.org/D123777

Add a new CMake file to expand on for more problematic configurations in the future. Related to #54645 Reviewed By: beanz, phosek, smeenai Differential Revision: https://reviews.llvm.org/D123777

tru · 2022-04-21T07:48:18Z

Warning has landed. I will close this issue now, feel free to re-open if you think there is more we can do here. Thanks everyone helping out!

LukeSkyw · 2022-09-29T19:27:19Z

@tru I get a:

CMake Error at /home/jedi/tmp/wasm-toolkit/llvm-project-release_15.x/llvm/cmake/modules/CheckProblematicConfigurations.cmake:14 (if):
  if given arguments:

    "STREQUAL" "MSVC"

  Unknown arguments specified
Call Stack (most recent call first):
  /home/jedi/tmp/wasm-toolkit/llvm-project-release_15.x/llvm/cmake/modules/HandleLLVMOptions.cmake:10 (include)
  CMakeLists.txt:149 (include)

CMAKE_CXX_COMPILER_ID does not seem to be defined at the moment of execution.

Compiling with:

cmake ../llvm -DLLVM_ENABLE_PROJECTS='clang;lld' \
  -DCMAKE_BUILD_TYPE=MinSizeRel \
  -DCMAKE_EXE_LINKER_FLAGS=-static \
  -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
  -DLLVM_TARGETS_TO_BUILD=WebAssembly \
  -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi;libunwind'

tru · 2022-09-29T19:47:37Z

Sounds like a compiler setup problem to me. You should check what the CMake logs say. If compiler ID is not set it means CMake failed to find the compiler or can't recognise it.

tru · 2022-09-29T19:48:53Z

If you have problems with it still and think it's a bug in LLVMs code please file a new issue so we can have the discussion there instead.

LukeSkyw · 2022-09-30T05:29:47Z

Thanks @tru. Compilation goes fine for a while before failing this way, binaries are created. I doubt my compiler setup is the problem. The problem might be what I am trying to achieve: statically linked clang. Created the issue: #58073

tru added clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang:codegen clang-cl labels Mar 30, 2022

tru added this to the LLVM 14.0.1 Release milestone Mar 30, 2022

EugeneZelenko added llvm:crash llvm:optimizations and removed clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang:codegen labels Mar 30, 2022

tru changed the title ~~Compiling LLVM 14.x with clang-cl and /arch:AVX crashes - but -march=skylake works?~~ Compiling LLVM 14.x with clang-cl and /arch:AVX or -march=sandybridge crashes. Mar 30, 2022

RKSimon added llvm:core and removed llvm:optimizations labels Apr 1, 2022

tstellar added the release:reviewed label Apr 6, 2022

tstellar closed this as completed Apr 11, 2022

tstellar added the release:merged label Apr 12, 2022

tstellar reopened this Apr 12, 2022

tstellar modified the milestones: LLVM 14.0.1 Release, LLVM 14.0.2 Release Apr 13, 2022

tru closed this as completed Apr 21, 2022

Compiling LLVM 14.x with clang-cl and /arch:AVX or -march=sandybridge crashes. #54645

Compiling LLVM 14.x with clang-cl and /arch:AVX or -march=sandybridge crashes. #54645

Comments

tru commented Mar 30, 2022 • edited

llvmbot commented Mar 30, 2022

llvmbot commented Mar 30, 2022

tru commented Mar 30, 2022

tru commented Mar 30, 2022

tru commented Mar 31, 2022

tru commented Mar 31, 2022

RKSimon commented Mar 31, 2022 • edited

RKSimon commented Mar 31, 2022

tru commented Mar 31, 2022

RKSimon commented Mar 31, 2022

davidbolvansky commented Mar 31, 2022

tru commented Mar 31, 2022

silvasean commented Mar 31, 2022 • edited

tru commented Mar 31, 2022

RKSimon commented Mar 31, 2022

tru commented Mar 31, 2022

silvasean commented Mar 31, 2022

tru commented Apr 1, 2022

joker-eph commented Apr 1, 2022

tru commented Apr 5, 2022

tstellar commented Apr 5, 2022

dexonsmith commented Apr 6, 2022

RKSimon commented Apr 6, 2022

sstamenova commented Apr 8, 2022

tstellar commented Apr 11, 2022

davidbolvansky commented Apr 12, 2022

RKSimon commented Apr 12, 2022

tru commented Apr 12, 2022

davidbolvansky commented Apr 12, 2022

tru commented Apr 12, 2022

tstellar commented Apr 13, 2022

RKSimon commented Apr 14, 2022

tru commented Apr 14, 2022

tru commented Apr 21, 2022

LukeSkyw commented Sep 29, 2022 • edited

tru commented Sep 29, 2022

tru commented Sep 29, 2022

LukeSkyw commented Sep 30, 2022 • edited

Compiling LLVM 14.x with `clang-cl` and `/arch:AVX` or `-march=sandybridge` crashes. #54645

Compiling LLVM 14.x with `clang-cl` and `/arch:AVX` or `-march=sandybridge` crashes. #54645

tru commented Mar 30, 2022 •

edited

RKSimon commented Mar 31, 2022 •

edited

silvasean commented Mar 31, 2022 •

edited

LukeSkyw commented Sep 29, 2022 •

edited

LukeSkyw commented Sep 30, 2022 •

edited