User Details
- User Since
- Dec 3 2015, 1:10 AM (344 w, 5 h)
Mon, Jun 13
Verified that the current patch also solves the problem I saw.
Thanks!
As I haven't been able to reproduce the problem manually myself I can't confirm that this fixes the problem, but it does seem likely.
Thanks!
I noticed that on one of our downstream (not public) buildbots the
Thu, Jun 9
When I run tests (check-all) on this commit I get the follwoing two failures:
Jun 7 2022
I wrote an issue about LICM behaving differently with/without debug information with this patch:
https://github.com/llvm/llvm-project/issues/55915
Jun 3 2022
Fixes https://github.com/llvm/llvm-project/issues/55848 as well.
Jun 2 2022
Is anyone here ever using llvm-stress?
I noticed that with this patch, llvm-stress seems to start producing code that llc crashes on, and it crashes even if I run on older llc versions.
One example:
llc -o /dev/null stress.ll
crashes with
llc: ../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5974: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc &, llvm::EVT, llvm::SDValue, llvm::SDValue, const llvm::SDNodeFlags): Assertion `VT.isInteger() && N2.getValueType().isInteger() && "Shifts only work on integers"' failed.
Or is the X86 backend just not up to date with opaque pointers yet?
Jun 1 2022
@steakhal : Thanks for the quick fix!
I see crashes like this with this patch:
May 31 2022
I've verified that the updated fix also solves the problem I saw.
Thanks!
May 30 2022
I noticed that the testcase Interpreter/execute.cpp starts failing with this patch when run/compiled with asan:
Failed Tests (1): Clang :: Interpreter/execute.cpp
Seen in the buildbot run
https://lab.llvm.org/buildbot/#/builders/5/builds/24221
May 20 2022
Thanks! I have confirmed this patch solves the crash I saw.
May 18 2022
I wrote an issue about a crash with this patch:
https://github.com/llvm/llvm-project/issues/55546
May 17 2022
The following starts crashing with this patch:
llc -O1 -o /dev/null bbi-69670_x86.ll
I get:
llc: ../lib/Transforms/Utils/LoopUtils.cpp:1385: int llvm::rewriteLoopExitValues(llvm::Loop *, llvm::LoopInfo *, llvm::TargetLibraryInfo *, llvm::ScalarEvolution *, const llvm::TargetTransformInfo *, llvm::SCEVExpander &, llvm::DominatorTree *, llvm::ReplaceExitVal, SmallVector<llvm::WeakTrackingVH, 16> &): Assertion `EVL->contains(L) && "LCSSA breach detected!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: ../../main-github/llvm/build-all/bin/llc -O1 -o /dev/null bbi-69670_x86.ll 1. Running pass 'Function Pass Manager' on module 'bbi-69670_x86.ll'. 2. Running pass 'Loop Pass Manager' on function '@func_1' 3. Running pass 'Loop Strength Reduction' on basic block '%for.cond6418' #0 0x0000000002abded3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../main-github/llvm/build-all/bin/llc+0x2abded3) #1 0x0000000002abbb4e llvm::sys::RunSignalHandlers() (../../main-github/llvm/build-all/bin/llc+0x2abbb4e) #2 0x0000000002abe256 SignalHandler(int) Signals.cpp:0:0 #3 0x00007fcb1f00e630 __restore_rt sigaction.c:0:0 #4 0x00007fcb1c755387 raise (/lib64/libc.so.6+0x36387) #5 0x00007fcb1c756a78 abort (/lib64/libc.so.6+0x37a78) #6 0x00007fcb1c74e1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x00007fcb1c74e252 (/lib64/libc.so.6+0x2f252) #8 0x0000000002b80be3 llvm::rewriteLoopExitValues(llvm::Loop*, llvm::LoopInfo*, llvm::TargetLibraryInfo*, llvm::ScalarEvolution*, llvm::TargetTransformInfo const*, llvm::SCEVExpander&, llvm::DominatorTree*, llvm::ReplaceExitVal, llvm::SmallVector<llvm::WeakTrackingVH, 16u>&) (../../main-github/llvm/build-all/bin/llc+0x2b80be3) #9 0x00000000024c0a1e ReduceLoopStrength(llvm::Loop*, llvm::IVUsers&, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::LoopInfo&, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::MemorySSA*) LoopStrengthReduce.cpp:0:0 #10 0x00000000024ec121 (anonymous namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) LoopStrengthReduce.cpp:0:0 #11 0x0000000001b2d17b llvm::LPPassManager::runOnFunction(llvm::Function&) (../../main-github/llvm/build-all/bin/llc+0x1b2d17b) #12 0x000000000230895f llvm::FPPassManager::runOnFunction(llvm::Function&) (../../main-github/llvm/build-all/bin/llc+0x230895f) #13 0x000000000230f398 llvm::FPPassManager::runOnModule(llvm::Module&) (../../main-github/llvm/build-all/bin/llc+0x230f398) #14 0x0000000002308f2d llvm::legacy::PassManagerImpl::run(llvm::Module&) (../../main-github/llvm/build-all/bin/llc+0x2308f2d) #15 0x000000000074a073 main (../../main-github/llvm/build-all/bin/llc+0x74a073) #16 0x00007fcb1c741555 __libc_start_main (/lib64/libc.so.6+0x22555) #17 0x0000000000747670 _start (../../main-github/llvm/build-all/bin/llc+0x747670) Abort
I wrote
https://github.com/llvm/llvm-project/issues/55526
about a crash happening after this was recommited again in 41e142fdc7
May 13 2022
May 12 2022
I noticed when compiling with gcc 9.3.0 that we get a bunch of new warnings with this patch:
[1/351] Building CXX object tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o ../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual] 57 | unsigned getManglingNumber(const VarDecl *VD, | ^~~~~~~~~~~~~~~~~ ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning: by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual] 80 | unsigned getManglingNumber(const TagDecl *TD, | ^~~~~~~~~~~~~~~~~ ../../clang/lib/AST/MicrosoftCXXABI.cpp:46:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::BlockDecl*)' was hidden [-Woverloaded-virtual] 46 | unsigned getManglingNumber(const BlockDecl *BD) override { | ^~~~~~~~~~~~~~~~~ ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning: by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual] 80 | unsigned getManglingNumber(const TagDecl *TD, | ^~~~~~~~~~~~~~~~~ ../../clang/lib/AST/MicrosoftCXXABI.cpp:42:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::CXXMethodDecl*)' was hidden [-Woverloaded-virtual] 42 | unsigned getManglingNumber(const CXXMethodDecl *CallOperator) override { | ^~~~~~~~~~~~~~~~~ ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning: by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual] 80 | unsigned getManglingNumber(const TagDecl *TD, | ^~~~~~~~~~~~~~~~~
No idea if it's important or if gcc is overly picky.
May 11 2022
Did you notice this:
FAILED: unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o /home/buildbots/clang.11.0.0/bin/clang++ --gcc-toolchain=/opt/rh/devtoolset-7/root/usr -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iunittests/Support -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support -Iinclude -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/utils/unittest/googletest/include -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/utils/unittest/googlemock/include -fPIC -fvisibility-inlines-hidden -Werror -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wno-variadic-macros -Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -UNDEBUG -Wno-suggest-override -std=c++14 -MD -MT unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o -MF unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o.d -o unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o -c /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support/Casting.cpp In file included from /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support/Casting.cpp:9: /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:216:12: error: returning reference to local temporary object [-Werror,-Wreturn-stack-address] return Res2; ^~~~ /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:453:72: note: in instantiation of member function 'llvm::cast_convert_val<llvm::foo, const llvm::bar, const llvm::bar>::doit' requested here typename simplify_type<From>::SimpleType>::doit(f); ^ /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:564:36: note: in instantiation of member function 'llvm::CastInfo<llvm::foo, const llvm::bar, void>::doCast' requested here return CastInfo<To, const From>::doCast(Val); ^ /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:214:47: note: binding reference variable 'Res2' here typename cast_retty<To, FromTy>::ret_type Res2 = ^ 1 error generated.
from
https://lab.llvm.org/buildbot/#/builders/57/builds/17829/steps/6/logs/stdio
The following starts hanging in Codegen Prepare with this patch:
llc -O1 -o /dev/null bbi-69624.ll
May 10 2022
This seems to solve the crash I reported in
https://github.com/llvm/llvm-project/issues/55131
May 9 2022
I noticed that this patch isn't NFC.
[...]
Could you please give this another shoot at this @uabelho?
Not sure if I'm doing something wrong but I can't apply this patch on current top of tree (a4190037fac0)
May 8 2022
I've stumbled on the (seemingly) infinite execution with this patch as well. I found it with code generated by llvm-stress.
So
llc -march=x86-64 -mcpu=corei7 -o /dev/null foo.ll
hangs in
[2022-05-09 08:43:33.796049513] 0x80f9960 Executing Pass 'X86 DAG->DAG Instruction Selection' on Function 'autogen_SD18620'...
May 6 2022
Apr 26 2022
I wrote
https://github.com/llvm/llvm-project/issues/55100
about a crash starting to happen with this patch.
Apr 22 2022
The following starts to crash with this patch, and it still crashes on current top of tree 036aeac36c:
opt -passes='require<ir-similarity>' -o /dev/null bbi-68950.ll
We get
opt: ../include/llvm/Support/Casting.h:269: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = llvm::Instruction, Y = llvm::Value]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all/bin/opt -passes=require<ir-similarity> -o /dev/null /home/uabelho/bbi-68950.ll Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): build-all/bin/opt(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x2cbf503] build-all/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x2cbd17e] build-all/bin/opt[0x2cbf886] /lib64/libpthread.so.0(+0xf630)[0x7f7bebb82630] /lib64/libc.so.6(gsignal+0x37)[0x7f7be92c9387] /lib64/libc.so.6(abort+0x148)[0x7f7be92caa78] /lib64/libc.so.6(+0x2f1a6)[0x7f7be92c21a6] /lib64/libc.so.6(+0x2f252)[0x7f7be92c2252] build-all/bin/opt(_ZN4llvm12IRSimilarity21IRSimilarityCandidate27createCanonicalRelationFromERS1_RNS_8DenseMapIjNS_8DenseSetIjNS_12DenseMapInfoIjvEEEES6_NS_6detail12DenseMapPairIjS7_EEEESC_+0x11e6)[0x1b835d6] build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findCandidatesERSt6vectorIPNS0_17IRInstructionDataESaIS4_EERS2_IjSaIjEE+0xa51)[0x1b84631] build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findSimilarityERNS_6ModuleE+0xec)[0x1b854ac] build-all/bin/opt(_ZN4llvm20IRSimilarityAnalysis3runERNS_6ModuleERNS_15AnalysisManagerIS1_JEEE+0x181)[0x1b85a81] build-all/bin/opt[0x2fe4320] build-all/bin/opt(_ZN4llvm15AnalysisManagerINS_6ModuleEJEE13getResultImplEPNS_11AnalysisKeyERS1_+0x20e)[0x245fb1e] build-all/bin/opt[0x2ff1258] build-all/bin/opt[0x2ff109d] build-all/bin/opt(_ZN4llvm11PassManagerINS_6ModuleENS_15AnalysisManagerIS1_JEEEJEE3runERS1_RS3_+0x208)[0x245d3d8] build-all/bin/opt(_ZN4llvm15runPassPipelineENS_9StringRefERNS_6ModuleEPNS_13TargetMachineEPNS_21TargetLibraryInfoImplEPNS_14ToolOutputFileES8_S8_S0_NS_8ArrayRefIS0_EENS9_INS_10PassPluginEEENS_8opt_tool10OutputKindENSD_12VerifierKindEbbbbb+0x3f9f)[0x78657f] build-all/bin/opt(main+0x3fad)[0x7972cd] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f7be92b5555] build-all/bin/opt[0x780ec0]
Apr 18 2022
Apr 17 2022
The new testcase
ELF_ehframe_large_static_personality_encodings.s
fails for me when I compile and run on a RHEL7 linux machine.
When I run
/repo/uabelho/master-github/llvm/build-all/bin/llvm-jitlink -debug-only=jitlink -noexec /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp
I get something that ends with
External symbols: 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - __gxx_personality_v0 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - _GLOBAL_OFFSET_TABLE_ 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - __cxa_begin_catch 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - __cxa_end_catch 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - __cxa_throw 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - _ZTIi 0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live - __cxa_allocate_exception Resolving symbols defined in /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp Issuing lookup for external symbols for /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp (may trigger materialization/linking of other graphs)... Starting link phase 3 for graph /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp JIT session error: Symbols not found: [ _ZTIi ] /repo/uabelho/master-github/llvm/build-all/bin/llvm-jitlink: Failed to materialize symbols: { (main, { pe_absptr, main, pe_indir_pcrel_sdata8, DW.ref.__gxx_personality_v0 }) }
Attaching the full output as foo.log.
Apr 14 2022
I noticed this produces broken code:
clang -cc1 -triple amdgcn-- -emit-llvm -o - -x c op.c
Apr 7 2022
This makes sense to me.
Apr 5 2022
Apr 4 2022
Mar 31 2022
Nice! I've verified that this solves the problem I saw.
Thanks!
Mar 30 2022
No idea what is happening yet but I've seen some pretty nasty memory consumption by opt that I bisected to this patch.
I've run some tests with this patch over night without problems. We end up in tryLastChanceRecoloring fairly often when running tests on our out-of-tree target so I have probably exercised the new code a bit at least.
Mar 29 2022
I wrote
https://github.com/llvm/llvm-project/issues/54615
about a crash that started happening with this patch.
Mar 28 2022
I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with this patch:
00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable] 00:22:48 unsigned framesWalked = 1; 00:22:48 ^ 00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable] 00:22:48 unsigned framesWalked = 1; 00:22:48 ^ 00:22:48 2 warnings generated.
Mar 24 2022
I've run some more testing with this patch reapplied locally without seeing problems so there at least doesn't seem to be anything that pops up at once for us.
(Always hard to know how much testing is "enough" when running fuzz testing though, but I've run tests for two nights without seeing anything else than the problem above that has already been fixed.)
Mar 21 2022
Heads up that I've seen the following assert (added in 6253b77da) trigger in one of our downstream tests:
opt: ../lib/Transforms/Vectorize/SLPVectorizer.cpp:8066: void llvm::slpvectorizer::BoUpSLP::BlockScheduling::calculateDependencies(llvm::slpvectorizer::BoUpSLP::ScheduleData *, bool, llvm::slpvectorizer::BoUpSLP *): Assertion `DepDest && "must be in schedule window"' failed.
I'll try to extract a reproducer and come back.
I noticed that if compilng with ubsan
-DLLVM_USE_SANITIZER='Undefined'
you get the following error when compiling llc with this patch:
Mar 18 2022
Mar 17 2022
It seems like the new testcase fails when run with sanitizers:
https://lab.llvm.org/buildbot/#/builders/5/builds/20833
Did you see this sanitizer error when running global_record.c?
Mar 13 2022
Mar 11 2022
This broke compiling with
-DLLVM_ENABLE_Z3_SOLVER=ON
Mar 8 2022
Mar 6 2022
I've verified that the current patch solves the problem we see with glibc 2.17
Mar 4 2022
Thanks! The tests pass for me now with glibc 2.17
Mar 3 2022
I see the following failures with this commit:
FAIL: libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp (466 of 7808) ******************** TEST 'libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp' FAILED ******************** Script: -- : 'COMPILED WITH'; /repo/uabelho/master-github/llvm/build-all-builtins/./bin/clang++ /repo/uabelho/master-github/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp -v --target=x86_64-unknown-linux-gnu -nostdinc++ -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/x86_64-unknown-linux-gnu/c++/v1 -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/c++/v1 -I/repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/repo/uabelho/master-github/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -D_LIBCPP_DISABLE_AVAILABILITY -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -lc++experimental -L/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -Wl,-rpath,/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -L/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -Wl,-rpath,/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir/t.tmp.exe : 'EXECUTED AS'; "/app/vbuild/RHEL7-x86_64/python/3.8.0/bin/python3.8" /repo/uabelho/master-github/libcxx/test/../utils/run.py --execdir /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir --codesign_identity "" --env -- /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir/t.tmp.exe -- Exit Code: 250
Another somewhat similar case but with less different compiler flags needed:
build-all-builtins/bin/clang -finline-hint-functions -std=c99 -fsanitize=undefined -O2 'vla_sum_1.c' -o 'vla_sum_1.out' ./vla_sum_1.out
Result:
UndefinedBehaviorSanitizer:DEADLYSIGNAL ==160192==ERROR: UndefinedBehaviorSanitizer: BUS on unknown address (pc 0x00000042b6c9 bp 0x7fff7d630950 sp 0x1000100010001 T160192) ==160192==The signal is caused by a READ memory access. ==160192==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used. #0 0x42b6c9 (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x42b6c9) #1 0x42b857 (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x42b857) #2 0x7fa2c69b4554 (/lib64/libc.so.6+0x22554) (BuildId: e6847a931dd483773bab779dd3985b17c11caab2) #3 0x402cb4 (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x402cb4)
We see other problems that started appearing with this commit.
With
build-all-builtins/bin/clang -finline-hint-functions -fstack-protector-all -fwrapv -std=c99 -fsanitize=undefined -O3 'vla_sum_4.c' -fsanitize=undefined -l gcc_s -o 'vla_sum_4.out' ./vla_sum_4.out
we see
*** stack smashing detected ***: ./vla_sum_4.out terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7fc20889c697] /lib64/libc.so.6(+0x118652)[0x7fc20889c652] ./vla_sum_4.out[0x42b618] ./vla_sum_4.out[0x42b92d] ./vla_sum_4.out[0x42bb45] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fc2087a6555] ./vla_sum_4.out[0x402d25] ======= Memory map: ======== 00400000-0043f000 r-xp 00000000 fd:01 51014653 /repo/uabelho/master-github/llvm/vla_sum_4.out 0063f000-00640000 r--p 0003f000 fd:01 51014653 /repo/uabelho/master-github/llvm/vla_sum_4.out 00640000-00643000 rw-p 00040000 fd:01 51014653 /repo/uabelho/master-github/llvm/vla_sum_4.out 00643000-00f84000 rw-p 00000000 00:00 0 023ce000-023ef000 rw-p 00000000 00:00 0 [heap] 7fc208784000-7fc208948000 r-xp 00000000 fd:00 33598593 /usr/lib64/libc-2.17.so 7fc208948000-7fc208b47000 ---p 001c4000 fd:00 33598593 /usr/lib64/libc-2.17.so 7fc208b47000-7fc208b4b000 r--p 001c3000 fd:00 33598593 /usr/lib64/libc-2.17.so 7fc208b4b000-7fc208b4d000 rw-p 001c7000 fd:00 33598593 /usr/lib64/libc-2.17.so 7fc208b4d000-7fc208b52000 rw-p 00000000 00:00 0 7fc208b52000-7fc208b54000 r-xp 00000000 fd:00 34860521 /usr/lib64/libdl-2.17.so 7fc208b54000-7fc208d54000 ---p 00002000 fd:00 34860521 /usr/lib64/libdl-2.17.so 7fc208d54000-7fc208d55000 r--p 00002000 fd:00 34860521 /usr/lib64/libdl-2.17.so 7fc208d55000-7fc208d56000 rw-p 00003000 fd:00 34860521 /usr/lib64/libdl-2.17.so 7fc208d56000-7fc208e57000 r-xp 00000000 fd:00 34860522 /usr/lib64/libm-2.17.so 7fc208e57000-7fc209056000 ---p 00101000 fd:00 34860522 /usr/lib64/libm-2.17.so 7fc209056000-7fc209057000 r--p 00100000 fd:00 34860522 /usr/lib64/libm-2.17.so 7fc209057000-7fc209058000 rw-p 00101000 fd:00 34860522 /usr/lib64/libm-2.17.so 7fc209058000-7fc20905f000 r-xp 00000000 fd:00 34860529 /usr/lib64/librt-2.17.so 7fc20905f000-7fc20925e000 ---p 00007000 fd:00 34860529 /usr/lib64/librt-2.17.so 7fc20925e000-7fc20925f000 r--p 00006000 fd:00 34860529 /usr/lib64/librt-2.17.so 7fc20925f000-7fc209260000 rw-p 00007000 fd:00 34860529 /usr/lib64/librt-2.17.so 7fc209260000-7fc209277000 r-xp 00000000 fd:00 33555219 /usr/lib64/libpthread-2.17.so 7fc209277000-7fc209476000 ---p 00017000 fd:00 33555219 /usr/lib64/libpthread-2.17.so 7fc209476000-7fc209477000 r--p 00016000 fd:00 33555219 /usr/lib64/libpthread-2.17.so 7fc209477000-7fc209478000 rw-p 00017000 fd:00 33555219 /usr/lib64/libpthread-2.17.so 7fc209478000-7fc20947c000 rw-p 00000000 00:00 0 7fc20947c000-7fc209491000 r-xp 00000000 fd:00 34815442 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fc209491000-7fc209690000 ---p 00015000 fd:00 34815442 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fc209690000-7fc209691000 r--p 00014000 fd:00 34815442 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fc209691000-7fc209692000 rw-p 00015000 fd:00 34815442 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fc209692000-7fc2096b4000 r-xp 00000000 fd:00 34860516 /usr/lib64/ld-2.17.so 7fc20987d000-7fc209882000 rw-p 00000000 00:00 0 7fc2098a2000-7fc2098b3000 rw-p 00000000 00:00 0 7fc2098b3000-7fc2098b4000 r--p 00021000 fd:00 34860516 /usr/lib64/ld-2.17.so 7fc2098b4000-7fc2098b5000 rw-p 00022000 fd:00 34860516 /usr/lib64/ld-2.17.so 7fc2098b5000-7fc2098b6000 rw-p 00000000 00:00 0 7ffd12f86000-7ffd12fa8000 rw-p 00000000 00:00 0 [stack] 7ffd12fcc000-7ffd12fce000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abort
Feb 22 2022
Feb 21 2022
and here's the bbi-66447.c
I haven't looked into it yet, but we see cases of "ran out of registers during register allocation" with this patch, for code that compiled succesfully before.
Feb 17 2022
I wrote
https://github.com/llvm/llvm-project/issues/53905
that started happening with this patch.
Feb 16 2022
I can confirm that this patch fixes the miscompile I saw in
https://reviews.llvm.org/D115955#3322857
Feb 15 2022
No idea what's happening but I get this error on trunk
FAIL: libc++ :: libcxx/clang_tidy.sh.cpp (600 of 7776) ******************** TEST 'libc++ :: libcxx/clang_tidy.sh.cpp' FAILED ******************** Script: -- : 'RUN: at line 11'; clang-tidy /repo/uabelho/master-github/libcxx/test/libcxx/clang_tidy.sh.cpp --warnings-as-errors=* -header-filter=.* -- -Wno-unknown-warning-option -nostdinc++ -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/x86_64-unknown-linux-gnu/c++/v1 -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/c++/v1 -I/repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/repo/uabelho/master-github/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -D_LIBCPP_DISABLE_AVAILABILITY -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -- Exit Code: 1
I think I'm seeing a miscompile with this patch on trunk. Are we aware of any such problems?
Feb 13 2022
WIth EXPENSIVE_CHECKS this testcase now fails all the time.
So
build-all-expensive/bin/clang -cc1 -internal-isystem build-all-expensive/lib/clang/15.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -fblocks -analyze -analyzer-checker=core,nullability,apiModeling,debug.ExprInspection -verify ../clang/test/Analysis/trustnonnullchecker_test.m
fails with
clang: ../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h:100: clang::ento::ConstraintManager::ProgramStatePair clang::ento::ConstraintManager::assumeDual(clang::ento::ProgramStateRef, clang::ento::DefinedSVal): Assertion `assume(State, Cond, false) && "System is over constrained."' 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: build-all-expensive/bin/clang -cc1 -internal-isystem build-all-expensive/lib/clang/15.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -fblocks -analyze -analyzer-checker=core,nullability,apiModeling,debug.ExprInspection -verify ../clang/test/Analysis/trustnonnullchecker_test.m 1. <eof> parser at end of file 2. While analyzing stack: #0 Calling -[DictionarySubclass coder] 3. ../clang/test/Analysis/trustnonnullchecker_test.m:190:9: Error evaluating branch Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): build-all-expensive/bin/clang(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x2e66ae3] build-all-expensive/bin/clang(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x2e6475e] build-all-expensive/bin/clang[0x2e66e66] /lib64/libpthread.so.0(+0xf630)[0x7f5af3a04630] /lib64/libc.so.6(gsignal+0x37)[0x7f5af1137387] /lib64/libc.so.6(abort+0x148)[0x7f5af1138a78] /lib64/libc.so.6(+0x2f1a6)[0x7f5af11301a6] /lib64/libc.so.6(+0x2f252)[0x7f5af1130252] build-all-expensive/bin/clang[0x4143927] build-all-expensive/bin/clang(_ZN5clang4ento10ExprEngine13processBranchEPKNS_4StmtERNS0_18NodeBuilderContextEPNS0_12ExplodedNodeERNS0_15ExplodedNodeSetEPKNS_8CFGBlockESD_+0xaae)[0x44fd8de] build-all-expensive/bin/clang(_ZN5clang4ento10CoreEngine12HandleBranchEPKNS_4StmtES4_PKNS_8CFGBlockEPNS0_12ExplodedNodeE+0xa1)[0x44dafd1] build-all-expensive/bin/clang(_ZN5clang4ento10CoreEngine15ExecuteWorkListEPKNS_15LocationContextEjN4llvm18IntrusiveRefCntPtrIKNS0_12ProgramStateEEE+0x4a4)[0x44d9624] build-all-expensive/bin/clang[0x4118d2c] build-all-expensive/bin/clang[0x40fc6aa] build-all-expensive/bin/clang(_ZN5clang8ParseASTERNS_4SemaEbb+0x273)[0x45f2633] build-all-expensive/bin/clang(_ZN5clang14FrontendAction7ExecuteEv+0x106)[0x38464a6] build-all-expensive/bin/clang(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x144)[0x37c19e4] build-all-expensive/bin/clang(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x2a2)[0x3901152] build-all-expensive/bin/clang(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x5fa)[0xa2980a] build-all-expensive/bin/clang[0xa27c2f] build-all-expensive/bin/clang(main+0x2c73)[0xa277c3] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f5af1123555] build-all-expensive/bin/clang[0xa24849] Abort
Feb 9 2022
Feb 8 2022
Feb 2 2022
Feb 1 2022
We've seen a case where the output from opt is different with/without debug info and ended up bisection at this patch.
After reduction and fiddling it seems like it doesn't actually have to do with debug info at all but something else. Our best reproducer so far is as below.
Jan 31 2022
The following fails with this commit:
opt -passes='require<ir-similarity>' -o /dev/null bbi-65410.ll
Result:
opt: ../lib/Analysis/IRSimilarityIdentifier.cpp:998: void llvm::IRSimilarity::IRSimilarityCandidate::createCanonicalRelationFrom(llvm::IRSimilarity::IRSimilarityCandidate &, DenseMap<unsigned int, DenseSet<unsigned int> > &, DenseMap<unsigned int, DenseSet<unsigned int> > &): Assertion `Found && "Could not find matching value for source GVN"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all/bin/opt -passes=require<ir-similarity> -o /dev/null bbi-65410.ll #0 0x0000000002cbb993 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/opt+0x2cbb993) #1 0x0000000002cb960e llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x2cb960e) #2 0x0000000002cbbd16 SignalHandler(int) Signals.cpp:0:0 #3 0x00007fcc4be0e630 __restore_rt sigaction.c:0:0 #4 0x00007fcc49541387 raise (/lib64/libc.so.6+0x36387) #5 0x00007fcc49542a78 abort (/lib64/libc.so.6+0x37a78) #6 0x00007fcc4953a1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x00007fcc4953a252 (/lib64/libc.so.6+0x2f252) #8 0x0000000001b4f5aa llvm::IRSimilarity::IRSimilarityCandidate::createCanonicalRelationFrom(llvm::IRSimilarity::IRSimilarityCandidate&, llvm::DenseMap<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> >, llvm::DenseMapInfo<unsigned int, void>, llvm::detail::DenseMapPair<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> > > >&, llvm::DenseMap<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> >, llvm::DenseMapInfo<unsigned int, void>, llvm::detail::DenseMapPair<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> > > >&) (build-all/bin/opt+0x1b4f5aa) #9 0x0000000001b504d1 llvm::IRSimilarity::IRSimilarityIdentifier::findCandidates(std::vector<llvm::IRSimilarity::IRInstructionData*, std::allocator<llvm::IRSimilarity::IRInstructionData*> >&, std::vector<unsigned int, std::allocator<unsigned int> >&) (build-all/bin/opt+0x1b504d1) #10 0x0000000001b512ba llvm::IRSimilarity::IRSimilarityIdentifier::findSimilarity(llvm::Module&) (build-all/bin/opt+0x1b512ba) #11 0x0000000001b5185a llvm::IRSimilarityAnalysis::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x1b5185a) #12 0x0000000002fc43a0 llvm::detail::AnalysisPassModel<llvm::Module, llvm::IRSimilarityAnalysis, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>::Invalidator>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0 #13 0x000000000241321e llvm::AnalysisManager<llvm::Module>::getResultImpl(llvm::AnalysisKey*, llvm::Module&) (build-all/bin/opt+0x241321e) #14 0x0000000002fd0e88 llvm::RequireAnalysisPass<llvm::IRSimilarityAnalysis, llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0 #15 0x0000000002fd0ccd llvm::detail::PassModel<llvm::Module, llvm::RequireAnalysisPass<llvm::IRSimilarityAnalysis, llvm::Module, llvm::AnalysisManager<llvm::Module> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0 #16 0x0000000002410a98 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x2410a98) #17 0x000000000079e0a2 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::StringRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool) (build-all/bin/opt+0x79e0a2) #18 0x00000000007b0c74 main (build-all/bin/opt+0x7b0c74) #19 0x00007fcc4952d555 __libc_start_main (/lib64/libc.so.6+0x22555) #20 0x000000000079952c _start (build-all/bin/opt+0x79952c) Abort
Jan 25 2022
Anyone seen problems with this patch?
I have a case for my out-of-tree target where this patch causes two stores to be merged leading to a cycle in the DAG.
So in the initial DAG we have the following dependencies
store2 <- load1 <- load2 <- load3 <- store1
and then store2 and store1 are merged to store21 and we end up with dependencies like this:
store12 <- load1 <- load2 <- load3 <- store12
ie. load2 depends on both load3 and store12 so we have a broken DAG with a cycle in it.
So then we end up with
Operand not processed?0x882a240 t9: i16,ch = load<(load (s16) from %ir.next1.i)> t26, t8, undef:i16