Differential D146987
[Assignment Tracking] Enable by default Authored by Orlando on Mar 27 2023, 10:04 AM.
Details See https://discourse.llvm.org/t/rfc-enable-assignment-tracking/69399 This sets the -Xclang -fexperimental-assignment-tracking flag to the value enabled which means it will be enabled so long as none of the following are true: it's an LTO build, LLDB debugger tuning has been specified, or it's an O0 build (no work is done in any case if -g is not specified or -gmlt is used).
Diff Detail
Event TimelineComment Actions LGTM -- this is after all just a switch-throw to enable everything that's in tree already (which has all been reviewed). The expected compile-time regression on ReleaseLTO-g is roughly 1.2% right, in exchange for greater variable location coverage? What with the past RFCs and announcements, we should be fine for enabling this by default, let's pray for an easy ride through CI. Comment Actions
The compile time tracker is currently reporting around 1.5% for an LTO build. However, it's disabled for LTO at the moment until that can be improved. Comment Actions This patch (which enables assignment tracking) and D147312 breaks llvm runtime build for runtimes-armv7-unknown-linux-gnueabihf Error message: FAILED: libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o /b/s/w/ir/cache/goma/client/gomacc /b/s/w/ir/x/w/staging/llvm_build/./bin/clang++ --target=armv7-unknown-linux-gnueabihf --sysroot=/b/s/w/ir/x/w/cipd/linux -DLIBCXX_BUILDING_LIBCXXABI -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_ENABLE_ASSERTIONS -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB -D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/s/w/ir/x/w/llvm-llvm-project/libcxx/src -I/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1 -I/b/s/w/ir/x/w/staging/llvm_build/include/armv7-unknown-linux-gnueabihf/c++/v1 -I/b/s/w/ir/x/w/llvm-llvm-project/libcxxabi/include --target=armv7-unknown-linux-gnueabihf -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -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 -Wno-comment -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins=../staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins -ffile-prefix-map=/b/s/w/ir/x/w/llvm-llvm-project/= -no-canonical-prefixes -O2 -g -DNDEBUG -std=c++20 -fPIC -UNDEBUG -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -MD -MT libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -MF libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o.d -o libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -c /b/s/w/ir/x/w/llvm-llvm-project/libcxx/src/charconv.cpp fragment covers entire variable call void @llvm.dbg.value(metadata i32 %0, metadata !3116, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !3130 !3116 = !DILocalVariable(name: "__pred", arg: 3, scope: !3117, file: !3118, line: 23, type: !3121) fragment covers entire variable call void @llvm.dbg.value(metadata i64 %0, metadata !3652, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !3665 !3652 = !DILocalVariable(name: "__pred", arg: 3, scope: !3653, file: !3118, line: 23, type: !3656) fragment covers entire variable call void @llvm.dbg.value(metadata i32 %0, metadata !3116, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !3130 !3116 = !DILocalVariable(name: "__pred", arg: 3, scope: !3117, file: !3118, line: 23, type: !3121) fragment covers entire variable call void @llvm.dbg.value(metadata i64 %0, metadata !3651, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !3664 !3651 = !DILocalVariable(name: "__pred", arg: 3, scope: !3652, file: !3118, line: 23, type: !3655) fatal error: error in backend: Broken module found, compilation aborted! PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /b/s/w/ir/x/w/staging/llvm_build/./bin/clang++ --target=armv7-unknown-linux-gnueabihf --sysroot=/b/s/w/ir/x/w/cipd/linux -DLIBCXX_BUILDING_LIBCXXABI -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_ENABLE_ASSERTIONS -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB -D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/s/w/ir/x/w/llvm-llvm-project/libcxx/src -I/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1 -I/b/s/w/ir/x/w/staging/llvm_build/include/armv7-unknown-linux-gnueabihf/c++/v1 -I/b/s/w/ir/x/w/llvm-llvm-project/libcxxabi/include --target=armv7-unknown-linux-gnueabihf -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -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 -Wno-comment -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins=../staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins -ffile-prefix-map=/b/s/w/ir/x/w/llvm-llvm-project/= -no-canonical-prefixes -O2 -g -DNDEBUG -std=c++20 -fPIC -UNDEBUG -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -MD -MT libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -MF libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o.d -o libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -c /b/s/w/ir/x/w/llvm-llvm-project/libcxx/src/charconv.cpp 1. <eof> parser at end of file 2. Code generation #0 0x000055c427944a28 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/s/w/ir/x/w/staging/llvm_build/./bin/clang+++0x7e88a28) clang++: error: clang frontend command failed with exit code 70 (use -v to see invocation) Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 9d2b84ef6232c7aa75963526ff4092fb8d8a3b50) Target: armv7-unknown-linux-gnueabihf Thread model: posix InstalledDir: /b/s/w/ir/x/w/staging/llvm_build/./bin clang++: note: diagnostic msg: ******************** Example of failed build: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8785108885903505089/overview Please take a look. And please revert this change if it takes a while to fix. Thanks. Comment Actions We've also seen crashes with this patch, e.g. clang -cc1 -triple x86_64-unknown-linux -emit-obj -debug-info-kind=constructor -O1 bbi-80938.c crashes with clang: ../include/llvm/ADT/IntervalMap.h:1187: bool llvm::IntervalMap<unsigned int, unsigned int, 16, llvm::IntervalMapHalfOpenInfo<unsigned int> >::overlaps(KeyT, KeyT) const [KeyT = unsigned int, ValT = unsigned int, N = 16, Traits = llvm::IntervalMapHalfOpenInfo<unsigned int>]: Assertion `Traits::nonEmpty(a, b)' failed. PLEASE submit a bug report to https://developer.internal.ericsson.com/docs/bbi/languages/support/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: build-all/bin/clang -cc1 -triple x86_64-unknown-linux -emit-obj -debug-info-kind=constructor -O1 bbi-80938.c 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'bbi-80938.c'. 4. Running pass 'Assignment Tracking Analysis' on function '@main' #0 0x0000000003213388 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/clang+0x3213388) #1 0x0000000003210f1e llvm::sys::RunSignalHandlers() (build-all/bin/clang+0x3210f1e) #2 0x0000000003213a06 SignalHandler(int) Signals.cpp:0:0 #3 0x00007f483e5c8630 __restore_rt sigaction.c:0:0 #4 0x00007f483bd0f387 raise (/lib64/libc.so.6+0x36387) #5 0x00007f483bd10a78 abort (/lib64/libc.so.6+0x37a78) #6 0x00007f483bd081a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x00007f483bd08252 (/lib64/libc.so.6+0x2f252) #8 0x0000000002a749e9 llvm::IntervalMap<unsigned int, unsigned int, 16u, llvm::IntervalMapHalfOpenInfo<unsigned int>>::overlaps(unsigned int, unsigned int) const crtstuff.c:0:0 #9 0x0000000002a5e420 (anonymous namespace)::MemLocFragmentFill::run(FunctionVarLocsBuilder*) AssignmentTrackingAnalysis.cpp:0:0 #10 0x0000000002a567b9 llvm::AssignmentTrackingAnalysis::runOnFunction(llvm::Function&) (build-all/bin/clang+0x2a567b9) #11 0x0000000002bd91bf llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all/bin/clang+0x2bd91bf) #12 0x0000000002be00c8 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all/bin/clang+0x2be00c8) #13 0x0000000002bd9787 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/clang+0x2bd9787) #14 0x00000000034187fe clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) (build-all/bin/clang+0x34187fe) #15 0x000000000432c062 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) crtstuff.c:0:0 #16 0x0000000004dfeb53 clang::ParseAST(clang::Sema&, bool, bool) (build-all/bin/clang+0x4dfeb53) #17 0x0000000003c363e6 clang::FrontendAction::Execute() (build-all/bin/clang+0x3c363e6) #18 0x0000000003ba1724 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (build-all/bin/clang+0x3ba1724) #19 0x0000000003cfbafb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (build-all/bin/clang+0x3cfbafb) #20 0x0000000000a5b1fc cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (build-all/bin/clang+0xa5b1fc) #21 0x0000000000a57050 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0 #22 0x0000000000a55087 clang_main(int, char**, llvm::ToolContext const&) (build-all/bin/clang+0xa55087) #23 0x0000000000a66c91 main (build-all/bin/clang+0xa66c91) #24 0x00007f483bcfb555 __libc_start_main (/lib64/libc.so.6+0x22555) #25 0x0000000000a5277b _start (build-all/bin/clang+0xa5277b) Abort (core dumped) I've no idea if thiis is the same problem already reported above or not. Comment Actions The latest reland 3820e9a2b29a2e268319ed6635da0d59e18d736d still caused some issues to our internal workloads. Stay tuned... So far we have only found crashes with ThinLTO workloads. Comment Actions I'm seeing llc: ../../llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:6214: void llvm::SelectionDAGBuilder::visitIntrinsicCall(const CallInst &, unsigned int): Assertion `AssignmentTrackingEnabled && "expected assignment tracking to be enabled"' failed. with this patch on the following IR (just run llc on it) Comment Actions More specifically, thinlto + split debug. I'm not sure if my reduction is the same issue as @aeubanks has. Here's mine: Repro w/ clang -O1 -c reduced.ll -o /dev/null I don't see any assertions going off for this one. The stack trace I have just points to llvm::Value::stripPointerCasts. Lemme know if you need more info, but I'm hoping that file reproduces for you. Comment Actions this is the original repro that crashed but maybe differently (you'll need to remove the plugin arguments since our clang has some custom plugins) Comment Actions This one is interesting... there's a dbg.assign (an assignment tracking debug intrinsic) there: define void @_ZN3gfx31PointTest_VectorArithmetic_Test8TestBodyEv() {
entry:
call void @llvm.dbg.assign(metadata i1 undef, metadata !204, metadata !DIExpression(), metadata !210, metadata ptr null, metadata !DIExpression()), !dbg !211
ret void
}but the module flags don't contain the "assignment tracking is turned on" flag (!{i32 7, !"debug-info-assignment-tracking", i1 true}). !llvm.module.flags = !{!203}
!203 = !{i32 2, !"Debug Info Version", i32 3}If the reproducer below is the one used to create this one then I think the reduction process may have just cut the module flag. Do you know if you've hit this assertion from a source code reproducer? This is indeed a different issue to the first one - D148203 fixes this one. Thanks for these reproducers! Comment Actions Many thanks for all the feedback, Hmmmm, that feels like a legitimate IR input where the configuration of debug-info / intrinsics is just unexpected -- we probably shouldn't assert in that situation but gracefully degrade to interpreting a dbg.assign as a dbg.value. Comment Actions IR that passes the verifier generally shouldn't crash llvm, so an alternative would be to make a verifier check Comment Actions Thanks everyone for begin patient with this one. I've just pushed again after landing D148536. I am hoping that's the last issue... I am watching the buildbots and chromium build page. Comment Actions I think we may have an issue due to this. I'm basing that on the blamelist, but I'm still bisecting our build, which may take some time to confirm. Can you take a look, and revert if it's not a quick fix? FAILED: obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o ../../../recipe_cleanup/clanghgeznbv_/bin/clang -MD -MF obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o.d -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -DNDEBUG=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DSTDC_HEADERS=1 -DHAVE_ENDIAN_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAV... clang: llvm/lib/IR/IntrinsicInst.cpp:140: void llvm::DbgVariableIntrinsic::replaceVariableLocationOp(Value *, Value *): Assertion `DbgAssignAddrReplaced && "OldValue must be dbg.assign addr if unused in DIArgList"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: ../../../recipe_cleanup/clanghgeznbv_/bin/clang -MD -MF obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o.d -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -DNDEBUG=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DSTDC_HEADERS=1 -DHAVE_ENDIAN_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -... 1. <eof> parser at end of file 2. Optimizer #0 0x00005588b5bbe168 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../../recipe_cleanup/clanghgeznbv_/bin/clang+0x7fc2168) clang: error: clang frontend command failed with exit code 134 (use -v to see invocation) Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 4bb64daf34aa3463786f531b5b42d13ab5f47869) Target: x86_64-unknown-fuchsia Thread model: posix InstalledDir: ../../../recipe_cleanup/clanghgeznbv_/bin clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: clang-crashreports/nir_opt_uniform_atomics-73fdef.c clang: note: diagnostic msg: clang-crashreports/nir_opt_uniform_atomics-73fdef.sh clang: note: diagnostic msg: ******************** Comment Actions
That looks related to assignment tracking to me. I'm unlikely to get the chance to look into it until tomorrow morning (UK / BST), so I've reverted it for now. Thanks for the info. Comment Actions Thanks, just one note: I think ideally a reland commit includes the original commit message, i.e. See https://discourse.llvm.org/t/rfc-enable-assignment-tracking/69399 ... :) Comment Actions Here are reduced cases. I didn't bother bisecting flags, but the test case is quite small struct a {};
struct b {
struct b *c;
struct b *d;
};
_Bool e;
inline void g(struct b *p1) {
struct b *f = 0;
e = f->d == f;
if (e)
p1->c = p1;
}
typedef struct {
struct a h;
struct b i;
struct b j;
} k;
inline _Bool l() {
k *m = 0;
return (&m->i)->d && (&m->j)->d;
}
_Bool n(void);
static _Bool p() {
l();
k o;
g(&o.i);
return 0;
}
_Bool n() {
p();
return 0;
}Comment Actions Seeing how this has been in and out quite a bit, I figure it's worth explaning my understanding of what's failing and why. Just so it doesn't look like we're needlessly fuzzing other peoples CI. Three kinds of failures so far:
The former is expected, the middle annoying, but the latter is the riskiest as it's not something we'd anticipated at all, so has the greatest potential pop up randomly. If there's futher breakage then I think our preferred approach is relaxing the verifier conditions: this doesn't lead to producing incorrect variable locations (AFAIUI), it means describing nonexistant portions of variables (that other passes will drop) or producing overlapping fragments that make some portions of variables needlessly "optimised out". Which isn't a regression versus the existing implementation of tracking partially-promoted variables. Comment Actions For the record, this also breaks (broke?) Halide: Assertion failed: (!(Elmt.getFragmentOrDefault() == Next.getFragmentOrDefault())), function operator(), file AssignmentTrackingAnalysis.cpp, line 2020. Comment Actions That's a new one -- would you be able to give some context and a reproducer? Thanks for reporting! Comment Actions Yep -- as of LLVM commit 3c9083f6757cbaf6f8d6c601586d99a11faf642e, Halide is still broken. Working on a repro case now. Comment Actions
This is regrettably large, but easy to repro:
Assertion failed: (!(Elmt.getFragmentOrDefault() == Next.getFragmentOrDefault())), function operator(), file AssignmentTrackingAnalysis.cpp, line 2020. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /Users/srj/llvm-17-install/bin/llc gpu_object_lifetime.runtime.ll 1. Running pass 'Function Pass Manager' on module 'gpu_object_lifetime.runtime.ll'. 2. Running pass 'Assignment Tracking Analysis' on function '@halide_debug_to_file' #0 0x0000000106b92697 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/srj/llvm-17-install/bin/llc+0x101fab697) #1 0x0000000106b90638 llvm::sys::RunSignalHandlers() (/Users/srj/llvm-17-install/bin/llc+0x101fa9638) #2 0x0000000106b92e40 SignalHandler(int) (/Users/srj/llvm-17-install/bin/llc+0x101fabe40) #3 0x00007ff81c079dfd (/usr/lib/system/libsystem_platform.dylib+0x7ff800336dfd) #4 0x00007ff7bb316720 #5 0x00007ff81bfafd24 (/usr/lib/system/libsystem_c.dylib+0x7ff80026cd24) #6 0x00007ff81bfaf0cb (/usr/lib/system/libsystem_c.dylib+0x7ff80026c0cb) #7 0x00000001076f1da3 void std::__1::__sort<buildOverlapMapAndRecordDeclares(llvm::Function&, FunctionVarLocsBuilder*, llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, void>> const&, llvm::DenseMap<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>, llvm::DenseMapInfo<llvm::Instruction const*, void>, llvm::detail::DenseMapPair<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>>>&, unsigned int&)::$_1&, llvm::DebugVariable*>(llvm::DebugVariable*, llvm::DebugVariable*, buildOverlapMapAndRecordDeclares(llvm::Function&, FunctionVarLocsBuilder*, llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, void>> const&, llvm::DenseMap<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>, llvm::DenseMapInfo<llvm::Instruction const*, void>, llvm::detail::DenseMapPair<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>>>&, unsigned int&)::$_1&) (.cold.4) (/Users/srj/llvm-17-install/bin/llc+0x102b0ada3) #8 0x0000000105e3b47d void std::__1::__sort<buildOverlapMapAndRecordDeclares(llvm::Function&, FunctionVarLocsBuilder*, llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, void>> const&, llvm::DenseMap<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>, llvm::DenseMapInfo<llvm::Instruction const*, void>, llvm::detail::DenseMapPair<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>>>&, unsigned int&)::$_1&, llvm::DebugVariable*>(llvm::DebugVariable*, llvm::DebugVariable*, buildOverlapMapAndRecordDeclares(llvm::Function&, FunctionVarLocsBuilder*, llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, void>> const&, llvm::DenseMap<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>, llvm::DenseMapInfo<llvm::Instruction const*, void>, llvm::detail::DenseMapPair<llvm::Instruction const*, llvm::SmallVector<std::__1::pair<llvm::VariableID, llvm::at::AssignmentInfo>, 1u>>>&, unsigned int&)::$_1&) (/Users/srj/llvm-17-install/bin/llc+0x10125447d) #9 0x0000000105e2ff8c (anonymous namespace)::AssignmentTrackingLowering::run(FunctionVarLocsBuilder*) (/Users/srj/llvm-17-install/bin/llc+0x101248f8c) #10 0x0000000105e2ce9e llvm::AssignmentTrackingAnalysis::runOnFunction(llvm::Function&) (/Users/srj/llvm-17-install/bin/llc+0x101245e9e) #11 0x000000010649a082 llvm::FPPassManager::runOnFunction(llvm::Function&) (/Users/srj/llvm-17-install/bin/llc+0x1018b3082) #12 0x00000001064a08a1 llvm::FPPassManager::runOnModule(llvm::Module&) (/Users/srj/llvm-17-install/bin/llc+0x1018b98a1) #13 0x000000010649a687 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/Users/srj/llvm-17-install/bin/llc+0x1018b3687) #14 0x0000000104beed44 compileModule(char**, llvm::LLVMContext&) (/Users/srj/llvm-17-install/bin/llc+0x100007d44) #15 0x0000000104beca4f main (/Users/srj/llvm-17-install/bin/llc+0x100005a4f) Comment Actions Hello, I also noticed this potentially causing problems for scalable vectors: Comment Actions I'm also running into issues due to this commit. Unfortunately, the issues don't seem to be entirely deterministic. They can be reproduced with https://martin.st/temp/python-preproc.c: $ clang -target i686-w64-mingw32 -c -g -O3 python-preproc.c Assertion failed: (!(Elmt.getFragmentOrDefault() == Next.getFragmentOrDefault())), function operator(), file AssignmentTrackingAnalysis.cpp, line 2020. I'm seeing this on macOS with LLVM built with Xcode's clang. On Linux, built with either GCC or Clang, I don't run into this issue. When running the seemingly working compiler build on Linux in valgrind, I'm hitting use of uninitialized data: ==3054473== Conditional jump or move depends on uninitialised value(s) ==3054473== at 0x4900F0A: llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef<llvm::Value*>, bool, std::optional<unsigned int>, llvm::Type*) (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x48C865F: foldGEPOfGEP(llvm::GEPOperator*, llvm::Type*, bool, llvm::ArrayRef<llvm::Value*>) (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x48D1285: llvm::ConstantFoldGetElementPtr(llvm::Type*, llvm::Constant*, bool, std::optional<unsigned int>, llvm::ArrayRef<llvm::Value*>) (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x4900CEF: llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef<llvm::Value*>, bool, std::optional<unsigned int>, llvm::Type*) (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x4025C21: simplifyGEPInst(llvm::Type*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, bool, llvm::SimplifyQuery const&, unsigned int) [clone .constprop.0] (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x4036E5F: simplifyInstructionWithOperands(llvm::Instruction*, llvm::ArrayRef<llvm::Value*>, llvm::SimplifyQuery const&, unsigned int) [clone .constprop.0] (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) ==3054473== by 0x4037423: llvm::simplifyInstruction(llvm::Instruction*, llvm::SimplifyQuery const&) (in /home/martin/code/llvm-project-bisect/llvm/build/bin/clang-17) Comment Actions /me grumbles about all the world being a VAX, @mstorsjo I can't replicate the crash, but can replicate the valgrind jump-on-uninitialized-value with a small reproducer [0] that doesn't feature any debug-info, using opt --passes=early-cse reduced.ll. The trace I've reduced around: ==609193== Conditional jump or move depends on uninitialised value(s) ==609193== at 0x5653F8B: simplifyICmpInst(unsigned int, llvm::Value*, llvm::Value*, llvm::SimplifyQuery const&, unsigned int) (in /fast/fs/llvm-main/build/bin/opt) ==609193== by 0x5654F22: simplifyICmpInst(unsigned int, llvm::Value*, llvm::Value*, llvm::SimplifyQuery const&, unsigned int) (in /fast/fs/llvm-main/build/bin/opt) ==609193== by 0x566107B: simplifyInstructionWithOperands(llvm::Instruction*, llvm::ArrayRef<llvm::Value*>, llvm::SimplifyQuery const&, unsigned int) (in /fast/fs/llvm-main/build/bin/opt) ==609193== by 0x566181E: llvm::simplifyInstruction(llvm::Instruction*, llvm::SimplifyQuery const&) (in /fast/fs/llvm-main/build/bin/opt) I've been building rG61967bbc7d4e9 using ubuntu's packaged clang-9. I can't be completely certain, but seemingly a user of PatternMatch::BinaryOp_match doesn't check that the pattern matched before examining the pattern? It doesn't reproduce in a stage2 RelWithDebInfo build, which is highly suspicious and feels like it's my environment. Could you confirm it's definitely assignment-tracking at fault by using -Xclang -fexperimental-assignment-tracking=forced to enable and -Xclang -fexperimental-assignment-tracking=disabled to disable, which should control the behaviour if it's AT at fault. @dmgreen Aaahh, yes, we hadn't considered SVE at all. I think there's a natural solution, which is to treat such stores as indicating a variable is memory-homed at that point, although determining the size could be troublesome. I'll leave that to @Orlando . @srj I'm unable to reproduce that assertion on linux with rG61967bbc7d4e9, however it looks like that assertion doesn't expect to have two identical objects compared with each other. Some light googling suggests that it's permissible for std::sort to do that, and some people complain about it, so I suppose in some environments that assertion is ill formed. We should be able to fix that with a small refinement. Many thanks for reporting the problems all. [0] https://gist.github.com/jmorse/55da51f56d9c756fa77b42e705bdc674 Comment Actions Ok, it's possible that bit was a red herring here. It didn't show up in a build of Clang instrumented with asan either.
The -Xclang -fexperimental-assignment-tracking=disabled flag does make the assert that shows up when built with Xcode's clang go away at least. It doesn't affect the valgrind failure, so that's indeed unrelated. So there's something in Clang/LLVM which behaves differently, to the point of triggering a failed assert, when built with Xcode's Clang (reproed with two different Xcode versions) but not on Linux (with GCC or Clang, at least with a possibly older Clang). Comment Actions Ah, you're right, it's actually the same assertion message that @srj reported which I totally skipped over. Currently I suspect that's due to different std::sort implementations. Comment Actions ...std::stable_sort()? (But more seriously, could we please revert all of this unless/until a fix is imminent? Our testing is dead in the water at the moment.) Comment Actions Should have been reverted in rG0ba922f60046 earlier today, are you still experiencing the same behaviour with that patch? Comment Actions Thanks everyone for your reports and help, it's really appreciated. You're right there. Fixed the assertion firing in D149137, but the behaviour isn't quite right yet so I've opened a bug for it here llvm.org/PR62346. @mstorsjo and @srj, the issue with the faulty assertion in a std::sort predicate is fixed with D149045. I found an additional assertion failure on the chromium build page (for pigweed) which I've fixed in D149135. Comment Actions Given our repeated back-and-forth, it's probably better to do some pre-testing: @MaskRay @paulkirth we've got a command line switch for enabling this, are there any fuchsia / chromium facilities for pull-request-builds that we'd be able to use to pre-check this; or if those aren't available would you have any time to fire off a build with this flag enabled to see if there's further trouble? Apologies for the burden, the end reward is sounder and more complete variable locations when debugging though. Comment Actions @jmorse Sorry it took me a bit to set up, but I ran an experiment in our CI that reverted the change that disabled this as default and tried it for x86. It looks like this patch is working OK for us now: https://ci.chromium.org/raw/build/logs.chromium.org/fuchsia/led/paulkirth_google.com/df38ff794f44284ff34f63e5dc1f1d41b25225b1241c14eff15a9f0a4b189afb/+/build.proto?server=chromium-swarm.appspot.com I'm reasonably confident that should mean you won't run into issues. The caveat here is that I can't easily launch experiments across all combinations of platforms and hardware, so it's possible there may still be an issue. I think that's unlikely given how this has been manifesting, so I'd say you're good to try again in our perspective. Comment Actions Thank you for doing that, that's really helpful. Just to double check - that is a non-LTO but otherwise optimised build of fuchsia? Once D149137 has been accepted I'll be able to try this again. Comment Actions It's a standard optimized build of Fuchsia. Some parts will use LTO or ThinLTO. This is the CI that verifies our toolchain, so debug here refers to the compiler being a stage-2 compiler w/ asserts enabled and split debug info. The Fuchsia build also always compiles with complete (split) debug information for both kernel and userland. It may also be relevant that the majority of Fuchsia is built at -Os. The kernel typically builds at -O2 or higher, but userland is always optimized for size. Empirically, we've had better size savings from -Os over -Oz, so incase that's relevant. Comment Actions Got crash for RISC-V on top of trunk: [kitoc@hsinchu02 build]$ cat x.c
typedef __rvv_uint32m4_t a;
void b() { a c; }
[kitoc@hsinchu02 build]$ bin/clang -target riscv64-elf x.c -O -g
clang-14: /home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/DebugInfo.cpp:2162: bool llvm::AssignmentTrackingPass::runOnFunction(llvm::Function&): Assertion `llvm::any_of(Markers, [DDI](DbgAssignIntrinsic *DAI) { return DebugVariableAggregate(DAI) == DebugVariableAggregate(DDI); })' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /scratch1/kitoc/llvm-workspace/build/bin/clang-14 -cc1 -triple riscv64-unknown-unknown-elf -emit-obj -disable-free -clear-ast-before-backend -main-file-name x.c -mrelocation-model static -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -fno-verbose-asm -mconstructor-aliases -nostdsysteminc -target-cpu generic-rv64 -target-feature +m -target-feature +a -target-feature +c -target-feature -e -target-feature -f -target-feature -d -target-feature -h -target-feature -zihintpause -target-feature -zfhmin -target-feature -zfh -target-feature -zfinx -target-feature -zdinx -target-feature -zhinxmin -target-feature -zhinx -target-feature -zba -target-feature -zbb -target-feature -zbc -target-feature -zbs -target-feature -zbkb -target-feature -zbkc -target-feature -zbkx -target-feature -zknd -target-feature -zkne -target-feature -zknh -target-feature -zksed -target-feature -zksh -target-feature -zkr -target-feature -zkn -target-feature -zks -target-feature -zkt -target-feature -zk -target-feature -zmmul -target-feature -v -target-feature -zvl32b -target-feature -zvl64b -target-feature -zvl128b -target-feature -zvl256b -target-feature -zvl512b -target-feature -zvl1024b -target-feature -zvl2048b -target-feature -zvl4096b -target-feature -zvl8192b -target-feature -zvl16384b -target-feature -zvl32768b -target-feature -zvl65536b -target-feature -zve32x -target-feature -zve32f -target-feature -zve64x -target-feature -zve64f -target-feature -zve64d -target-feature -zicbom -target-feature -zicboz -target-feature -zicbop -target-feature -zicntr -target-feature -zicsr -target-feature -zifencei -target-feature -zihpm -target-feature -zawrs -target-feature -svnapot -target-feature -svpbmt -target-feature -svinval -target-feature -xsfvcp -target-feature -xtheadba -target-feature -xtheadbb -target-feature -xtheadbs -target-feature -xtheadcmo -target-feature -xtheadcondmov -target-feature -xtheadfmemidx -target-feature -xtheadmac -target-feature -xtheadmemidx -target-feature -xtheadmempair -target-feature -xtheadsync -target-feature -xtheadvdot -target-feature -xventanacondops -target-feature -experimental-smaia -target-feature -experimental-ssaia -target-feature -experimental-zihintntl -target-feature -experimental-zca -target-feature -experimental-zcb -target-feature -experimental-zcd -target-feature -experimental-zcf -target-feature -experimental-zcmt -target-feature -experimental-zfa -target-feature -experimental-zicond -target-feature -experimental-zvfh -target-feature -experimental-ztso -target-feature -experimental-zvbb -target-feature -experimental-zvbc -target-feature -experimental-zvkg -target-feature -experimental-zvkn -target-feature -experimental-zvkned -target-feature -experimental-zvkng -target-feature -experimental-zvknha -target-feature -experimental-zvknhb -target-feature -experimental-zvks -target-feature -experimental-zvksed -target-feature -experimental-zvksg -target-feature -experimental-zvksh -target-feature -experimental-zvkt -target-feature +relax -target-feature -save-restore -target-abi lp64 -msmall-data-limit 8 -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fcoverage-compilation-dir=/home/kitoc/llvm-workspace/build -resource-dir /scratch1/kitoc/llvm-workspace/build/lib/clang/17 -internal-isystem /scratch1/kitoc/llvm-workspace/build/lib/clang/17/include -internal-isystem /scratch1/kitoc/llvm-workspace/build/bin/../lib/clang-runtimes/riscv64-elf/include -O1 -fdebug-compilation-dir=/home/kitoc/llvm-workspace/build -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/x-2feb04.o -x c x.c
1. <eof> parser at end of file
2. Optimizer
#0 0x00007fe505ca91a2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:22
#1 0x00007fe505ca9265 PrintStackTraceSignalHandler(void*) /home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:675:1
#2 0x00007fe505ca6cca llvm::sys::RunSignalHandlers() /home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Signals.cpp:104:20
#3 0x00007fe505ca8b0b SignalHandler(int) /home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x00007fe5050fff10 (/lib/x86_64-linux-gnu/libc.so.6+0x3ef10)
#5 0x00007fe5050ffe87 raise /build/glibc-CVJwZb/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x00007fe5051017f1 abort /build/glibc-CVJwZb/glibc-2.27/stdlib/abort.c:81:0
#7 0x00007fe5050f13fa __assert_fail_base /build/glibc-CVJwZb/glibc-2.27/assert/assert.c:89:0
#8 0x00007fe5050f1472 (/lib/x86_64-linux-gnu/libc.so.6+0x30472)
#9 0x00007fe506d098b3 llvm::AssignmentTrackingPass::runOnFunction(llvm::Function&) /home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/DebugInfo.cpp:2167:27
#10 0x00007fe506d09c40 llvm::AssignmentTrackingPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/DebugInfo.cpp:2213:13
#11 0x00007fe50d648435 llvm::detail::PassModel<llvm::Module, llvm::AssignmentTrackingPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/kitoc/llvm-workspace/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:90:3
#12 0x00007fe506f12aad llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/kitoc/llvm-workspace/llvm-project/llvm/include/llvm/IR/PassManager.h:521:20
#13 0x00007fe50d6063c8 (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>&, std::unique_ptr<llvm::ToolOutputFile, std::default_delete<llvm::ToolOutputFile>>&) /home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1055:12
#14 0x00007fe50d606969 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) /home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1113:21
#15 0x00007fe50d607aad clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) /home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1274:25
#16 0x00007fe50ddf644d clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:384:24
#17 0x00007fe4ff5689ea clang::ParseAST(clang::Sema&, bool, bool) /home/kitoc/llvm-workspace/llvm-project/clang/lib/Parse/ParseAST.cpp:183:14
#18 0x00007fe50a89da61 clang::ASTFrontendAction::ExecuteAction() /home/kitoc/llvm-workspace/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1166:11
#19 0x00007fe50ddf11fa clang::CodeGenAction::ExecuteAction() /home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1174:5
#20 0x00007fe50a89d31c clang::FrontendAction::Execute() /home/kitoc/llvm-workspace/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1060:38
#21 0x00007fe50a7ad7ac clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/kitoc/llvm-workspace/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1049:42
#22 0x00007fe50f2103d7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/kitoc/llvm-workspace/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:264:38
#23 0x0000560e31f227a5 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /home/kitoc/llvm-workspace/llvm-project/clang/tools/driver/cc1_main.cpp:251:40
#24 0x0000560e31f0ed4d ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) /home/kitoc/llvm-workspace/llvm-project/clang/tools/driver/driver.cpp:366:20
#25 0x0000560e31f0f2af clang_main(int, char**, llvm::ToolContext const&) /home/kitoc/llvm-workspace/llvm-project/clang/tools/driver/driver.cpp:407:26
#26 0x0000560e31f46d79 main /home/kitoc/llvm-workspace/build/tools/clang/tools/driver/clang-driver.cpp:15:58
#27 0x00007fe5050e2c87 __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:344:0
#28 0x0000560e31f0d1ba _start (/scratch1/kitoc/llvm-workspace/build/bin/clang-14+0x3b1ba)
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 17.0.0 (git@github.com:llvm/llvm-project.git e3afe0b89de57662e411f8cc14f6229782ec86ff)
Target: riscv64-unknown-unknown-elf
Thread model: posix
InstalledDir: /home/kitoc/llvm-workspace/build/bin
clang: note: diagnostic msg:Comment Actions Looks like this is causing a crash on current main: https://github.com/llvm/llvm-project/issues/62838 Please take a look and revert the commit if it requires longer to fix. Comment Actions Hey, found another error that occurs when building Android that looks to be different from @MaskRay's revert. Obviously only happens with asserts (DLLVM_ENABLE_ASSERTIONS), this is my cmake: cmake \ -DLLVM_ENABLE_ASSERTIONS=On \ -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld;lldb;mlir" \ -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -GNinja \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_USE_LINKER=lld \ -DCMAKE_C_FLAGS="-Wall -Wunused-but-set-variable" \ -DCMAKE_CXX_FLAGS="-Wall -Wunused-but-set-variable" \ /path/to/llvm/llvm I've reduced the problem down to: $ cat /tmp/repro.c #include <complex.h> void f() { long double complex r1; } $ bin/clang -c -O2 -g -ftrivial-auto-var-init=zero /tmp/repro.c clang: /usr/local/google/home/mitchp/llvm/llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp:228: static bool llvm::DebugHandlerBase::isUnsignedDIType(const DIType *): Assertion `(Encoding == dwarf::DW_ATE_unsigned || Encoding == dwarf::DW_ATE_unsigned_char || Encoding == dwarf::DW_ATE_signed || Encoding == dwarf::DW_ATE_signed_char || Encoding == dwarf::DW_ATE_float || Encoding == dwarf::DW_ATE_UTF || Encoding == dwarf::DW_ATE_boolean || (Ty->getTag() == dwarf::DW_TAG_unspecified_type && Ty->getName() == "decltype(nullptr)")) && "Unsupported encoding"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: bin/clang -c -O2 -g -ftrivial-auto-var-init=zero /tmp/repro.c 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/tmp/repro.c'. 4. Running pass 'X86 Assembly Printer' on function '@f' #0 0x000055fc688d6c08 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (bin/clang+0x783fc08) #1 0x000055fc688d4a8e llvm::sys::RunSignalHandlers() (bin/clang+0x783da8e) #2 0x000055fc68846c26 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x00007f29e0a5af90 (/lib/x86_64-linux-gnu/libc.so.6+0x3bf90) #4 0x00007f29e0aa9ccc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #5 0x00007f29e0a5aef2 raise ./signal/../sysdeps/posix/raise.c:27:6 #6 0x00007f29e0a45472 abort ./stdlib/abort.c:81:7 #7 0x00007f29e0a45395 _nl_load_domain ./intl/loadmsgcat.c:1177:9 #8 0x00007f29e0a53df2 (/lib/x86_64-linux-gnu/libc.so.6+0x34df2) #9 0x000055fc69763b8d (bin/clang+0x86ccb8d) #10 0x000055fc697ba18d llvm::DwarfUnit::addConstantValue(llvm::DIE&, unsigned long, llvm::DIType const*) (bin/clang+0x872318d) #11 0x000055fc6979e634 llvm::DwarfCompileUnit::constructVariableDIEImpl(llvm::DbgVariable const&, bool) (bin/clang+0x8707634) #12 0x000055fc6979cb3f llvm::DwarfCompileUnit::createAndAddScopeChildren(llvm::LexicalScope*, llvm::DIE&) (bin/clang+0x8705b3f) #13 0x000055fc6979edaa llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) (bin/clang+0x8707daa) #14 0x000055fc69782329 llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) (bin/clang+0x86eb329) #15 0x000055fc69764e44 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) (bin/clang+0x86cde44) #16 0x000055fc6974eed7 llvm::AsmPrinter::emitFunctionBody() (bin/clang+0x86b7ed7) #17 0x000055fc675fdcb0 llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) X86AsmPrinter.cpp:0:0 #18 0x000055fc67dc9660 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (bin/clang+0x6d32660) #19 0x000055fc682de4b7 llvm::FPPassManager::runOnFunction(llvm::Function&) (bin/clang+0x72474b7) #20 0x000055fc682e6ca2 llvm::FPPassManager::runOnModule(llvm::Module&) (bin/clang+0x724fca2) #21 0x000055fc682defc7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (bin/clang+0x7247fc7) #22 0x000055fc6902f963 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) (bin/clang+0x7f98963) #23 0x000055fc694c3051 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) CodeGenAction.cpp:0:0 #24 0x000055fc6ab688b6 clang::ParseAST(clang::Sema&, bool, bool) (bin/clang+0x9ad18b6) #25 0x000055fc693e140f clang::FrontendAction::Execute() (bin/clang+0x834a40f) #26 0x000055fc69351bfd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (bin/clang+0x82babfd) #27 0x000055fc694bbe96 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (bin/clang+0x8424e96) #28 0x000055fc664a62a7 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (bin/clang+0x540f2a7) #29 0x000055fc664a1e3e ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0 #30 0x000055fc691c7ad9 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::$_0>(long) Job.cpp:0:0 #31 0x000055fc68846966 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (bin/clang+0x77af966) #32 0x000055fc691c6f32 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (bin/clang+0x812ff32) #33 0x000055fc691840d9 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (bin/clang+0x80ed0d9) #34 0x000055fc69184387 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (bin/clang+0x80ed387) #35 0x000055fc691a35ca clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (bin/clang+0x810c5ca) #36 0x000055fc664a11b1 clang_main(int, char**, llvm::ToolContext const&) (bin/clang+0x540a1b1) #37 0x000055fc664b27c1 main (bin/clang+0x541b7c1) #38 0x00007f29e0a4618a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 #39 0x00007f29e0a46245 call_init ./csu/../csu/libc-start.c:128:20 #40 0x00007f29e0a46245 __libc_start_main ./csu/../csu/libc-start.c:368:5 #41 0x000055fc6649e221 _start (bin/clang+0x5407221) clang: error: clang frontend command failed with exit code 134 (use -v to see invocation) clang version 17.0.0 (https://github.com/llvm/llvm-project.git 8dec295af0352fccb5825dc08e4ec21cb9ffe010) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/google/home/mitchp/llvm-build/opt/bin clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/repro-99fc04.c clang: note: diagnostic msg: /tmp/repro-99fc04.sh clang: note: diagnostic msg: ******************** Comment Actions Thanks for the report and the tiny reproducer! I've written D151795 to address this. Comment Actions
That was fixed in D151326. I think we should be okay to re-enable this now. The first assertion was a bit of an edge case; I hadn't handled negative out of bounds accesses. The second issue ocurred due to DW_ATE_complex_float not being supported in a helper function, on a code path only hit with assignment tracking as a result of trying harder to preserve variable locations. |