[llvm-bugs] [Bug 48058] New: [EarlyCSE] Assertion in EarlyCSE
https://bugs.llvm.org/show_bug.cgi?id=48058
Bug ID: 48058
Summary: [EarlyCSE] Assertion in EarlyCSE
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: chenzheng1...@hotmail.com
CC: llvm-bugs@lists.llvm.org
```
define i8 @nabs_different_constants(i8 %a) {
%neg = sub i8 0, %a
%cmp1 = icmp slt i8 %a, 0
%cmp2 = icmp sge i8 %a, 0
%m1 = select i1 %cmp1, i8 %a, i8 %neg
%m2 = select i1 %cmp2, i8 %neg, i8 %a
%r = xor i8 %m2, %m1
ret i8 %r
}
```
opt 6.ll -S -early-cse -earlycse-debug-hash
```
llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:433: static bool
llvm::DenseMapInfo<{anonymous}::SimpleValue>::isEqual({anonymous}::SimpleValue,
{anonymous}::SimpleValue): Assertion `!Result || (LHS.isSentinel() && LHS.Inst
== RHS.Inst) || getHashValueImpl(LHS) == getHashValueImpl(RHS)' failed.
```
Seems the requirement for same hash value for same semantic instruction is
quite fragile.
For above case, we get true return value for the two selects `%m1` and `%m2` in
`isEqualImpl`. But we get diff hash values for them in `getHashValueImpl`.
`%m1` is recognized as a ABS while `%m2` is not, so their hash values are
computed with different operands combination in `getHashValueImpl`.
If we want to add more equal patterns in `isEqualImpl`, it is quite hard to
ensure the hash values for same semantic instructions same for all cases. My
motivated case is to support following case:
```
define i64 @foo1(i16 %0, i64 %1, i64 %2) {
entry:
%cmp1 = icmp ult i16 %0, 43
%cond1 = select i1 %cmp1, i64 %1, i64 %2
%cmp2 = icmp ugt i16 %0, 42
%cond2 = select i1 %cmp2, i64 %2, i64 %1
%ret = xor i64 %cond1, %cond2
ret i64 %ret
}
```
we should be able to recognize that `%cond1` and `%cond2` are the same, so the
function should just return zero.
No idea about how to fix this. Need a more smart way to deal the hash values of
the equal instructions. Any thoughts?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26936 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-03 Type: Bug New issue 26936 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26936 Detailed Report: https://oss-fuzz.com/testcase?key=5757580271681536 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isValueDependent() && "Expression evaluator can't be called on a dependent expr clang::Expr::EvaluateKnownConstInt EvaluateStmt Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202006110252:202006121812 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5757580271681536 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47741] [AMDGPU][MC][GFX1030] v_mac_f32 should not be supported
https://bugs.llvm.org/show_bug.cgi?id=47741 Dmitry changed: What|Removed |Added Fixed By Commit(s)||1e75668821f7 Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37417] [InstCombine] canonicalize IR to funnel shift intrinsics
https://bugs.llvm.org/show_bug.cgi?id=37417 Bug 37417 depends on bug 46896, which changed state. Bug 46896 Summary: InstCombine - extend matchRotate to handle funnel shifts https://bugs.llvm.org/show_bug.cgi?id=46896 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46896] InstCombine - extend matchRotate to handle funnel shifts
https://bugs.llvm.org/show_bug.cgi?id=46896 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Simon Pilgrim --- AggressiveInstCombine's foldGuardedRotateToFunnelShift was generalized to foldGuardedFunnelShift by D90625/rG59b22e495c15 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48059] New: polly crashes while running pass 'Polly - Create polyhedral description of Scops': Assertion `!ArrayAccess && "More then one array access for instruction"' failed
https://bugs.llvm.org/show_bug.cgi?id=48059 Bug ID: 48059 Summary: polly crashes while running pass 'Polly - Create polyhedral description of Scops': Assertion `!ArrayAccess && "More then one array access for instruction"' failed Product: Polly Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: zhendong...@inf.ethz.ch CC: llvm-bugs@lists.llvm.org [536] % clangtk -v clang version 12.0.0 (https://github.com/llvm/llvm-project.git 1667d23e585c13835c66b8d61c2d5ef93f196dd5) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /local/suz-local/opfuzz/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 [537] % [537] % clangtk -Os -mllvm -polly -c small.c [538] % clangtk -O2 -c small.c [539] % [539] % clangtk -O2 -mllvm -polly -c small.c clangtk: /local/suz-local/software/clangbuild/llvm-project/polly/include/polly/ScopInfo.h:1427: polly::MemoryAccess* polly::ScopStmt::getArrayAccessOrNULLFor(const llvm::Instruction*) const: Assertion `!ArrayAccess && "More then one array access for instruction"' 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: clangtk -O2 -mllvm -polly -c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'small.c'. 4. Running pass 'Region Pass Manager' on function '@e' 5. Running pass 'Polly - Create polyhedral description of Scops' on basic block '%for.end12' #0 0x561356bf6a0c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x3238a0c) #1 0x561356bf46e4 llvm::sys::RunSignalHandlers() (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x32366e4) #2 0x561356bf4975 llvm::sys::CleanupOnSignal(unsigned long) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x3236975) #3 0x561356b5e2b8 CrashRecoverySignalHandler(int) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x31a02b8) #4 0x7f1d5aa6d8a0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0) #5 0x7f1d5971ef47 raise /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #6 0x7f1d597208b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0 #7 0x7f1d5971042a __assert_fail_base /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0 #8 0x7f1d597104a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2) #9 0x561357b79f16 polly::Scop::lookupBasePtrAccess(polly::MemoryAccess*) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41bbf16) #10 0x561357b9dad0 polly::ScopBuilder::buildAliasGroup(llvm::SmallVector&, llvm::DenseSet >) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41dfad0) #11 0x561357b9e3c0 polly::ScopBuilder::buildAliasGroups() (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41e03c0) #12 0x561357b9e6a8 polly::ScopBuilder::buildAliasChecks() (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41e06a8) #13 0x561357ba5e20 polly::ScopBuilder::buildScop(llvm::Region&, llvm::AssumptionCache&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41e7e20) #14 0x561357ba65c5 polly::ScopBuilder::ScopBuilder(llvm::Region*, llvm::AssumptionCache&, llvm::AAResults&, llvm::DataLayout const&, llvm::DominatorTree&, llvm::LoopInfo&, polly::ScopDetection&, llvm::ScalarEvolution&, llvm::OptimizationRemarkEmitter&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41e85c5) #15 0x561357b7c1ac polly::ScopInfoRegionPass::runOnRegion(llvm::Region*, llvm::RGPassManager&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x41be1ac) #16 0x561355e37bb6 llvm::RGPassManager::runOnFunction(llvm::Function&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x2479bb6) #17 0x5613564bc7a8 llvm::FPPassManager::runOnFunction(llvm::Function&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x2afe7a8) #18 0x5613564bd2a9 llvm::FPPassManager::runOnModule(llvm::Module&) (/local/suz-local/software/local/clang-trunk/bin/clang-12+0x2aff2a9) #19 0x5
[llvm-bugs] [Bug 48060] New: LoopFuser crashes with Assertion `FC1.Preheader == (FC0.Peeled ? FC0.ExitBlock->getUniqueSuccessor() : FC0.ExitBlock)' failed.
https://bugs.llvm.org/show_bug.cgi?id=48060
Bug ID: 48060
Summary: LoopFuser crashes with Assertion `FC1.Preheader ==
(FC0.Peeled ? FC0.ExitBlock->getUniqueSuccessor() :
FC0.ExitBlock)' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: csz...@163.com
CC: llvm-bugs@lists.llvm.org
Created attachment 24125
--> https://bugs.llvm.org/attachment.cgi?id=24125&action=edit
small.bc
$clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
168db92465c504974274302a6a1a5d4a1580ccfe)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$clang -O3 -c -emit-llvm -femit-all-decls -mllvm -disable-llvm-optzns small.c
-o small.bc
$opt -sroa -loop-rotate -newgvn -jump-threading -loop-unroll -early-cse
-instcombine -loop-fusion small.bc -o small-opt.bc
opt:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/llvm/lib/Transforms/Scalar/LoopFuse.cpp:1330:
llvm::Loop* {anonymous}::LoopFuser::performFusion(const
{anonymous}::FusionCandidate&, const {anonymous}::FusionCandidate&): Assertion
`FC1.Preheader == (FC0.Peeled ? FC0.ExitBlock->getUniqueSuccessor() :
FC0.ExitBlock)' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt -sroa
-loop-rotate -newgvn -jump-threading -loop-unroll -early-cse -instcombine
-loop-fusion small.bc -o small-opt.bc
1. Running pass 'Function Pass Manager' on module 'small.bc'.
2. Running pass 'Loop Fusion' on function '@b'
#0 0x563c8f7d5f1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2beff1c)
#1 0x563c8f7d3bf4 llvm::sys::RunSignalHandlers()
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2bedbf4)
#2 0x563c8f7d3d63 SignalHandler(int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2bedd63)
#3 0x7f9b6e00f8a0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0)
#4 0x7f9b6ccc1f47 raise
/build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f9b6ccc38b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f9b6ccb342a __assert_fail_base
/build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0
#7 0x7f9b6ccb34a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2)
#8 0x563c8f6d4f13 (anonymous
namespace)::LoopFuser::performFusion((anonymous namespace)::FusionCandidate
const&, (anonymous namespace)::FusionCandidate const&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2aeef13)
#9 0x563c8f6d7add (anonymous namespace)::LoopFuser::fuseCandidates()
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2af1add)
#10 0x563c8f6d8bc3 (anonymous
namespace)::LoopFuser::fuseLoops(llvm::Function&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2af2bc3)
#11 0x563c8f6da953 (anonymous
namespace)::LoopFuseLegacy::runOnFunction(llvm::Function&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2af4953)
#12 0x563c8effaa48 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2414a48)
#13 0x563c8effb549 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2415549)
#14 0x563c8effa2c6 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x24142c6)
#15 0x563c8d4633da main
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x87d3da)
#16 0x7f9b6cca4b97 __libc_start_main
/build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:344:0
#17 0x563c8d5178ea _start
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+
[llvm-bugs] [Bug 47991] Assertion in Sparse conditional constant propagation
https://bugs.llvm.org/show_bug.cgi?id=47991 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||d68bed0fa94e --- Comment #1 from Florian Hahn --- Thanks for the report! Looks like an inconsistency with how vectors with all same constant ranges are bitcasted. Should be fixed with https://reviews.llvm.org/rGd68bed0fa94e -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47997] InstCombine misses C0-(C1-X) optimization
https://bugs.llvm.org/show_bug.cgi?id=47997 Roman Lebedev changed: What|Removed |Added Fixed By Commit(s)||e465f9c3036b28bdbdbef03eee8 ||fd022a3b6dcbf, ||c009d11bdac4a7f4a3a8ae85e42 ||da053828a6f24 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Roman Lebedev --- e465f9c3036b28bdbdbef03eee8fd022a3b6dcbf taught negator about the subj transform, since it does appear to be beneficial always. The C0-(C1+X) case, however, is not generally beneficial, so i simply moved it's specific fold earlier, so it fires again for C0=0. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48061] New: Code sinking pass crashes with Assertion `NodeA && "A must be in the tree"' failed.
https://bugs.llvm.org/show_bug.cgi?id=48061
Bug ID: 48061
Summary: Code sinking pass crashes with Assertion `NodeA && "A
must be in the tree"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: csz...@163.com
CC: llvm-bugs@lists.llvm.org
Created attachment 24126
--> https://bugs.llvm.org/attachment.cgi?id=24126&action=edit
small.bc
$clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
ba10c514c9712b99197935a82f0df8d285752bdf)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$clang -O3 -c -emit-llvm -femit-all-decls -mllvm -disable-llvm-optzns small.c
-o small.bc
$opt -gvn -correlated-propagation -sink small.bc -o small-opt.bc
opt:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:483:
NodeT* llvm::DominatorTreeBase::findNearestCommonDominator(NodeT*, NodeT*) const [with NodeT =
llvm::BasicBlock; bool IsPostDom = false]: Assertion `NodeA && "A must be in
the tree"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt -gvn
-correlated-propagation -sink small.bc -o small-opt.bc
1. Running pass 'Function Pass Manager' on module 'small.bc'.
2. Running pass 'Code sinking' on function '@e'
#0 0x56246397a8ec llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c1a8ec)
#1 0x5624639785c4 llvm::sys::RunSignalHandlers()
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c185c4)
#2 0x562463978733 SignalHandler(int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c18733)
#3 0x7f50df9298a0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0)
#4 0x7f50de5dbf47 raise
/build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f50de5dd8b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f50de5cd42a __assert_fail_base
/build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0
#7 0x7f50de5cd4a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2)
#8 0x562463856a07 iterativelySinkInstructions(llvm::Function&,
llvm::DominatorTree&, llvm::LoopInfo&, llvm::AAResults&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2af6a07)
#9 0x562463199db8 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2439db8)
#10 0x56246319a8b9 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x243a8b9)
#11 0x562463199636 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2439636)
#12 0x5624615e7df4 main
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x887df4)
#13 0x7f50de5beb97 __libc_start_main
/build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:344:0
#14 0x56246169c43a _start
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x93c43a)
Aborted (core dumped)
$cat small.c
int a[];
short b;
int d;
void e() {
for (;;) {
if (b) {
int c = d;
if (a)
continue;
}
-d;
}
}
This bug may be introduced by "int a[]". When I compile this program using
clang, it produces the following warnings.
$clang -O3 -c -emit-llvm -femit-all-decls -mllvm -disable-llvm-optzns small.c
-o small.bc
small.c:8:11: warning: address of array 'a' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (a)
~~ ^
small.c:11:5: warning: expression result unused [-Wunused-value]
-d;
^~
small.c:1:5: warning: tentative array definition assumed to have one element
int a[];
^
3 warnings generated.
However, if I change "int a[]" as
[llvm-bugs] Issue 25498 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator=
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25498 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator= https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25498#c1 ClusterFuzz testcase 4839046243942400 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011020601:202011030620 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25980 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25980 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase:: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25980#c1 ClusterFuzz testcase 5205193405497344 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011020601:202011030620 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48062] New: STB_LOCAL symbol found at index >= .symtab's sh_info
https://bugs.llvm.org/show_bug.cgi?id=48062 Bug ID: 48062 Summary: STB_LOCAL symbol found at index >= .symtab's sh_info Product: lld Version: unspecified Hardware: Other OS: other Status: NEW Severity: release blocker Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: xavi@tutanota.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com I am using llvm-project commit 8fc424f26bf1ea1471bd770a1b4eee4545c2bc96 with two additional patches for preliminary MIPS I support (see https://github.com/llvm/llvm-project/compare/release/11.x...XaviDCR92:release/11.x) and zig (https://github.com/ziglang/zig) commit b30a765b95cf666409c1e5324718a7c8c60af4af for an application targeted to the FPU-less MIPS R3000A featured on the original Sony PlayStation. The application uses mipsel-unknown-elf-as for the assembly files, which are later linked by lld when calling zig. The application used to build on llvm-10.x (plus the experimental patches) and older versions of zig, but does no longer build on llvm-11.x and latest zig. After some discussion on the #zig channel, I was encouraged to report this issue here based on the "lld:error: " messages shown below. As an alternative, I have tried to assemble the assembly files directly from zig, but unfortunately the assembler does not recognize the "rfe" (return from exception) MIPS I instruction for some unknown reason: This is the output when building everything from zig: --- $ make zig build-exe src/main.zig -Ddprintf=printf -L. -I/home/xavier/psxsdk-src/libpsx/include -I/home/xavier/psxsdk-src/libpsx/include/sys /home/xavier/psxsdk-src/libpsx/src/atexit.c /home/xavier/psxsdk-src/libpsx/src/cdrom.c /home/xavier/psxsdk-src/libpsx/src/cop.c /home/xavier/psxsdk-src/libpsx/src/exception.c /home/xavier/psxsdk-src/libpsx/src/gpu.c /home/xavier/psxsdk-src/libpsx/src/libc.c /home/xavier/psxsdk-src/libpsx/src/memcard.c /home/xavier/psxsdk-src/libpsx/src/memory.c /home/xavier/psxsdk-src/libpsx/src/pad.c /home/xavier/psxsdk-src/libpsx/src/psxsdk.c /home/xavier/psxsdk-src/libpsx/src/setup.c /home/xavier/psxsdk-src/libpsx/src/sio.c /home/xavier/psxsdk-src/libpsx/src/spu.c /home/xavier/psxsdk-src/libpsx/src/util.c /home/xavier/psxsdk-src/libpsx/src/libc/error.c /home/xavier/psxsdk-src/libpsx/src/libc/misc.c /home/xavier/psxsdk-src/libpsx/src/libc/printf.c /home/xavier/psxsdk-src/libpsx/src/libc/qsort.c /home/xavier/psxsdk-src/libpsx/src/libc/scanf.c /home/xavier/psxsdk-src/libpsx/src/libc/stat.c /home/xavier/psxsdk-src/libpsx/src/libc/string.c /home/xavier/psxsdk-src/libpsx/src/libc/strings.c /home/xavier/psxsdk-src/libpsx/src/libc/unistd.c /home/xavier/psxsdk-src/libpsx/src/cdromh.s /home/xavier/psxsdk-src/libpsx/src/exc1.s /home/xavier/psxsdk-src/libpsx/src/syscalls.s /home/xavier/psxsdk-src/libpsx/src/start/start.s /home/xavier/psxsdk-src/libpsx/src/runexe/stage2.s -target mipsel-freestanding-none --single-threaded -mcpu mips1+soft_float -Tpsx.ld error(compilation): clang failed with stderr: zig: warning: argument unused during compilation: '-fno-caret-diagnostics' [-Wunused-command-line-argument] zig: warning: argument unused during compilation: '-ffreestanding' [-Wunused-command-line-argument] zig: warning: argument unused during compilation: '-D dprintf=printf' [-Wunused-command-line-argument] /home/xavier/psxsdk-src/libpsx/src/exc1.s:95:2: error: unknown instruction, did you mean: rem? rfe ^ /home/xavier/psxsdk-src/libpsx/src/exc1.s:1:1: error: unable to build C object: clang exited with code 1 /home/xavier/psxsdk/bin/elf2exe main cdimg/main.exe -mark_eur mipsel-unknown-elf-objcopy: 'main': No such file Could not open objcopy output at main.bin. Check your permissions. Aborting. make: *** [Makefile:32: cdimg/main.exe] Error 255 --- And this is the output when assembling with mipsel-unknown-elf-as and compiling and linking from zig: --- $ make mipsel-unknown-elf-as /home/xavier/psxsdk-src/libpsx/src/cdromh.s -o obj/cdromh.o -msoft-float -march=mips1 -mabi=32 mipsel-unknown-elf-as /home/xavier/psxsdk-src/libpsx/src/exc1.s -o obj/exc1.o -msoft-float -march=mips1 -mabi=32 mipsel-unknown-elf-as /home/xavier/psxsdk-src/libpsx/src/syscalls.s -o obj/syscalls.o -msoft-float -march=mips1 -mabi=32 mipsel-unknown-elf-as /home/xavier/psxsdk-src/libpsx/src/start/start.s -o obj/start.o -msoft-float -march=mips1 -mabi=32 mipsel-unknown-elf-as /home/xavier/psxsdk-src/libpsx/src/runexe/stage2.s -o obj/stage2.o -msoft-float -march=mips1 -mabi=32 zig build-exe src/main.zig -Ddprintf=printf -L. -I/home/xavier/psxsdk-src/libpsx/include -I/home/x
[llvm-bugs] Issue 24830 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: Val && "isa<> used on a null pointer"
Updates: Labels: Deadline-Approaching Comment #1 on issue 24830 by sheriffbot: llvm:clang-objc-fuzzer: ASSERT: Val && "isa<> used on a null pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24830#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48063] New: Merge 0fca6517118d435f9c2d7afe6135fd5f357509b5 into 11.0.1 release
https://bugs.llvm.org/show_bug.cgi?id=48063 Bug ID: 48063 Summary: Merge 0fca6517118d435f9c2d7afe6135fd5f357509b5 into 11.0.1 release Product: libraries Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: jjo...@quarkslab.com, llvm-bugs@lists.llvm.org Blocks: 47800 Please merge https://github.com/llvm/llvm-project/commit/0fca6517118d435f9c2d7afe6135fd5f357509b5 into 11.0.1 release. This bug was reported in https://bugs.llvm.org/show_bug.cgi?id=47944. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47944] Assertion failure in WebAssemblyRegisterInfo::eliminateFrameIndex()
https://bugs.llvm.org/show_bug.cgi?id=47944 Heejin Ahn changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||0fca6517118d435f9c2d7afe613 ||5fd5f357509b5 --- Comment #3 from Heejin Ahn --- Fixed by https://github.com/llvm/llvm-project/commit/0fca6517118d435f9c2d7afe6135fd5f357509b5. I also asked to merge this in the next 11.0.1 release here: https://bugs.llvm.org/show_bug.cgi?id=48063 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48064] New: [StackColoring] Need Conservatively merge point pV = &(&Variable) in catch(Variable)
https://bugs.llvm.org/show_bug.cgi?id=48064
Bug ID: 48064
Summary: [StackColoring] Need Conservatively merge point pV =
&(&Variable) in catch(Variable)
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: xiang1.zh...@intel.com
CC: llvm-bugs@lists.llvm.org
We need conservatively merge pV = &(&Variable) for catch(Variable), EH libs may
write the catch value and return the Point (Type**) pV back.
This Point may be dangerously over written due to some work of objects'
destructor in try block. (The destructor may work after EH written)
In fact, for the catch point pV, there is usually a very long life range
guarded with TIME_START and TIME_END (usually almost through the whole
program),
but there is an potion "-stackcoloring-lifetime-start-on-first-use" which will
cut it shorter.
We should let pV conservatively use its TIME_START and TIME_END as its
live-range, not affected by the option
"-stackcoloring-lifetime-start-on-first-use"
We find this bug in a big win32 project, now the following case can reproduce.
Compile with: clang-cl -m32 -O2 -EHs test.cpp
test.cpp:
__attribute__((noinline,nothrow,weak)) void escape(int *p) { }
struct object {
int i;
object() {
i = 1;
}
~object() {
// if "object" and "exp" are assigned to the same slot,
// this assign will corrupt "exp".
i = ;
escape(&i);
}
};
inline void throwit() { throw 999; }
volatile int v;
inline void func() {
try {
object o;
throwit();
}
// "exp" is written by the OS when the "throw" occurs.
// Then the destructor is called, and the store-assign
// clobbers the value of "exp".
// The dereference of "exp" (with value ) causes a crash.
catch (int &exp) {
v = exp;
}
}
int main() {
func();
return 0;
}
//
Now we already have a patch to handle this. (https://reviews.llvm.org/D86673)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48065] New: loop-extract pass crashes with Assertion `!LocalChanged && "A pass trigged a code update but the update status is lost"' failed.
https://bugs.llvm.org/show_bug.cgi?id=48065
Bug ID: 48065
Summary: loop-extract pass crashes with Assertion
`!LocalChanged && "A pass trigged a code update but
the update status is lost"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: csz...@163.com
CC: llvm-bugs@lists.llvm.org
Created attachment 24129
--> https://bugs.llvm.org/attachment.cgi?id=24129&action=edit
small.bc
$clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
ba10c514c9712b99197935a82f0df8d285752bdf)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$clang -O3 -c -emit-llvm -femit-all-decls -mllvm -disable-llvm-optzns small.c
-o small.bc
$opt -sroa -structurizecfg -jump-threading -loop-extract small.bc -o
small-opt.bc
opt:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/llvm/include/llvm/PassAnalysisSupport.h:276:
AnalysisType& llvm::Pass::getAnalysisID(llvm::AnalysisID, llvm::Function&,
bool*) [with AnalysisType = llvm::DominatorTreeWrapperPass; llvm::AnalysisID =
const void*]: Assertion `!LocalChanged && "A pass trigged a code update but the
update status is lost"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments:
/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt -sroa
-structurizecfg -jump-threading -loop-extract small.bc -o small-opt.bc
1. Running pass 'Extract loops into new functions' on module 'small.bc'.
#0 0x5579dfa6c8ec llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c1a8ec)
#1 0x5579dfa6a5c4 llvm::sys::RunSignalHandlers()
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c185c4)
#2 0x5579dfa6a733 SignalHandler(int)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2c18733)
#3 0x7fd17ebd98a0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0)
#4 0x7fd17d88bf47 raise
/build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7fd17d88d8b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0
#6 0x7fd17d87d42a __assert_fail_base
/build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0
#7 0x7fd17d87d4a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2)
#8 0x5579df4005ee llvm::DominatorTree&
llvm::function_ref::callback_fn<(anonymous
namespace)::LoopExtractorLegacyPass::runOnModule(llvm::Module&)::'lambda'(llvm::Function&)>(long,
llvm::Function&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x25ae5ee)
#9 0x5579df400c37 (anonymous
namespace)::LoopExtractor::runOnModule(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x25aec37)
#10 0x5579df400f6c (anonymous
namespace)::LoopExtractorLegacyPass::runOnModule(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x25aef6c)
#11 0x5579df28b636 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x2439636)
#12 0x5579dd6d9df4 main
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x887df4)
#13 0x7fd17d86eb97 __libc_start_main
/build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:344:0
#14 0x5579dd78e43a _start
(/home/jack-zhou/Documents/llvm/llvm_truck/llvm-project/build/bin/opt+0x93c43a)
Aborted (core dumped)
$ cat small.c
int a, c;
char b;
float d() {
short e = 1;
for (; b <= 3; b) {
char f;
int g, h, i;
if (c)
continue;
for (; e;)
return a;
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48064] [StackColoring] Need Conservatively merge point pV = &(&Variable) in catch(Variable)
https://bugs.llvm.org/show_bug.cgi?id=48064 xiangzhangllvm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48066] New: [AArch64] copy incorrectly erased and discard zero-extend operation
https://bugs.llvm.org/show_bug.cgi?id=48066
Bug ID: 48066
Summary: [AArch64] copy incorrectly erased and discard
zero-extend operation
Product: libraries
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: chenge...@huawei.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
$ clang -O3 test-case.ll -w ;./a.out
c = -8917
$ clang -O0 test-case.ll -w ;./a.out
c = 4294958379
@b = dso_local local_unnamed_addr global { [3 x i8], i8, i8, i8, i8, i8 } { [3
x i8] undef, i8 -64, i8 74, i8 -9, i8 -1, i8 7 }, align 8
@c = common dso_local local_unnamed_addr global i64 0, align 8
@.str = private unnamed_addr constant [9 x i8] c"c = %ld\0A\00", align 1
define dso_local i8 @d(i64 %h) local_unnamed_addr {
entry:
ret i8 undef
}
declare dso_local i32 @printf(i8* nocapture readonly, ...) local_unnamed_addr
define dso_local i32 @main() local_unnamed_addr {
entry:
%bf.load = load i64, i64* bitcast ({ [3 x i8], i8, i8, i8, i8, i8 }* @b to
i64*), align 8
%0 = lshr i64 %bf.load, 30
%sext3 = shl nuw nsw i64 %0, 16
%sext = trunc i64 %sext3 to i32
%conv.i = ashr exact i32 %sext, 16
%conv.i.i = zext i32 %conv.i to i64
store i64 %conv.i.i, i64* @c, align 8
%call.i.i = tail call i32 (i8*, ...) @printf(i8* nonnull dereferenceable(1)
getelementptr inbounds ([9 x i8], [9 x i8]* @.str, i64 0, i64 0), i64
%conv.i.i)
%call4.i = tail call i8 bitcast (i8 (i64)* @d to i8 (i32, i32)*)(i32 0, i32
%conv.i)
ret i32 0
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48067] New: loop-reduce pass seems to drop debug location unnecessarily
https://bugs.llvm.org/show_bug.cgi?id=48067 Bug ID: 48067 Summary: loop-reduce pass seems to drop debug location unnecessarily Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: yuanboli...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 24130 --> https://bugs.llvm.org/attachment.cgi?id=24130&action=edit the IR file that triggers the potential bug Overview: In some cases, it seems that the loop-reduce pass will drop debug location unnecessarily. Steps to reproduce: Here is my version of llvm: $ clang++ --version clang version 12.0.0 (https://github.com/llvm/llvm-project.git f847094c246810d698d3d6d476f066e9b8779456) Target: x86_64-unknown-linux-gnu The IR file abc.ll is uploaded in the attachment. It is a file obtained from LLVM regression tests (llvm/test/Transforms/LoopStrengthReduce/X86/2008-08-14-ShadowIV.ll). We run debugify pass to generate artificial debugging information for the IR file to get the current version of abc.ll. $ /home/absozero/trunk/root-clang/bin/opt -loop-reduce abc.ll > result.bc $ /home/absozero/trunk/root-clang/bin/llvm-dis result.bc Then we can get result.ll as the output of the loop-reduce pass. $ diff abc.ll result.ll | head -n 30 (omit some irrelevant text).. 26,28c25,27 < %exitcond = icmp eq i32 %indvar.next, %umax, !dbg !27 < call void @llvm.dbg.value(metadata i1 %exitcond, metadata !17, metadata !DIExpression()), !dbg !27 < br i1 %exitcond, label %return, label %bb, !dbg !28 --- > call void @llvm.dbg.value(metadata i1 %scmp, metadata !17, metadata > !DIExpression()), !dbg !27 > %scmp = icmp uge i32 %indvar.next, %n > br i1 %scmp, label %return.loopexit, label %bb, !dbg !28 (omit some irrelevant text).. After the loop-reduce, the variable %exitcond is replaced by another variable %scmp. However, the variable %scmp seems to drop the debug location !dbg !27 unnecessarily. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
