[llvm-bugs] [Bug 41888] New: [AMDGPU][MC][GFX9+] s_call_b64 and s_cbranch_i_fork do not accept labels
https://bugs.llvm.org/show_bug.cgi?id=41888 Bug ID: 41888 Summary: [AMDGPU][MC][GFX9+] s_call_b64 and s_cbranch_i_fork do not accept labels Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org These instructions currently accept integer expressions as jump offsets but not labels. -- 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 14774 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: ASSERT: (isa(MaxNotTaken) || isa(MaxNotTaken)) && "No
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-05-15 Type: Bug New issue 14774 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: ASSERT: (isa(MaxNotTaken) || isa(MaxNotTaken)) && "No https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14774 Detailed report: https://oss-fuzz.com/testcase?key=5742121455190016 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_unroll Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_unroll Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (isa(MaxNotTaken) || isa(MaxNotTaken)) && "No llvm::ScalarEvolution::ExitLimit::ExitLimit llvm::ScalarEvolution::howManyGreaterThans Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802210603:201802211531 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5742121455190016 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 41878] wasm-ld: --trace doesn't indicate where some symbols are referenced
https://bugs.llvm.org/show_bug.cgi?id=41878 Sam Clegg changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #7 from Sam Clegg --- I've been asked to wait on landing that change.. so its not quite fixed yet. -- 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 13242 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b
Updates: Labels: Deadline-Approaching Comment #1 on issue 13242 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13242#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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41739, which changed state. Bug 41739 Summary: r359851 in release_80 branch causes regression in lld/test/ELF/eh-frame-hdr-augmentation.s https://bugs.llvm.org/show_bug.cgi?id=41739 What|Removed |Added Status|CONFIRMED |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 41739] r359851 in release_80 branch causes regression in lld/test/ELF/eh-frame-hdr-augmentation.s
https://bugs.llvm.org/show_bug.cgi?id=41739 Tom Stellard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|r355621 |r355621 r360792 --- Comment #2 from Tom Stellard --- Merged: r360792 -- 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 26956] [SLP] Missed opportunity to generate min/max reduction for fully unrolled loop
https://bugs.llvm.org/show_bug.cgi?id=26956 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Sanjay Patel --- (In reply to Simon Pilgrim from comment #8) > AFAICT the only remaining issue is what fast math flags the reduction should > depend on, which I think is the same thing keeping [Bug #23116] open. Yes, I think we can mark this as 'fixed' because SLP has been enhanced as requested, and we have the other report to track the FMF work (which is probably going to take multiple steps as noted there). Feel free to reopen if I got that wrong. -- 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 41878] wasm-ld: --trace doesn't indicate where some symbols are referenced
https://bugs.llvm.org/show_bug.cgi?id=41878 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dan Gohman --- Thanks! -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41602, which changed state. Bug 41602 Summary: Please merge lld r358547 for the 8.0.1 release https://bugs.llvm.org/show_bug.cgi?id=41602 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 41602] Please merge lld r358547 for the 8.0.1 release
https://bugs.llvm.org/show_bug.cgi?id=41602 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r358547 |r358547 r360791 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Merged: r360791 -- 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 20750] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://bugs.llvm.org/show_bug.cgi?id=20750 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||r360605 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Simon Pilgrim --- SGTM cheers! -- 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 41889] New: clang frontend command failed due to signal
https://bugs.llvm.org/show_bug.cgi?id=41889 Bug ID: 41889 Summary: clang frontend command failed due to signal Product: clang Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: tdeli...@uwaterloo.ca CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk clang encountered the following bug which I report as requested: #0 0xb4655f23 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x61cf23) #1 0xb4655ffd (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x61cffd) #2 0xb4654070 llvm::sys::RunSignalHandlers() (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x61b070) #3 0xb46541cb (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x61b1cb) #4 0xb7f24d10 0xd10 llvm::Use::getImpliedUser() const #5 0xb7f24d10 #6 0xb7f24d10 llvm::Use::getUser() const (+0xd10) #7 0xb477f357 llvm::FunctionLoweringInfo::set(llvm::Function const&, llvm::MachineFunction&, llvm::SelectionDAG*) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x746357) #8 0xb477f3c8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x7463c8) #9 0xb4b46169 (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0xb0d169) #10 0xb4c85945 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0xc4c945) #11 0xb62e22b7 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x22a92b7) #12 0xb490d801 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x8d4801) #13 0xb4739a98 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x700a98) #14 0xb4739b42 llvm::legacy::PassManager::run(llvm::Module&) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x700b42) #15 0xb473969a clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x70069a) #16 0xb473987f (/usr/lib/i386-linux-gnu/libLLVM-6.0.so.1+0x70087f) #17 0x0837ba10 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/llvm-6.0/bin/clang+0x837ba10) #18 0x088e80c0 clang::ASTFrontendAction::ExecuteAction() (/usr/lib/llvm-6.0/bin/clang+0x88e80c0) #19 0x08a1fb85 clang::CodeGenAction::ExecuteAction() (/usr/lib/llvm-6.0/bin/clang+0x8a1fb85) #20 0x0873399e clang::FrontendAction::Execute() (/usr/lib/llvm-6.0/bin/clang+0x873399e) #21 0x088e784a clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-6.0/bin/clang+0x88e784a) #22 0x08734ff9 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-6.0/bin/clang+0x8734ff9) #23 0x086fbf11 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-6.0/bin/clang+0x86fbf11) #24 0x087beea4 main (/usr/lib/llvm-6.0/bin/clang+0x87beea4) #25 0x083327bc __libc_start_main /build/glibc-GoSbp4/glibc-2.23/csu/../csu/libc-start.c:291:0 #26 0x0831ff0f _start (/usr/lib/llvm-6.0/bin/clang+0x831ff0f) /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x33)[0xb4655f23] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(+0x61cffd)[0xb4655ffd] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x40)[0xb4654070] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(+0x61b1cb)[0xb46541cb] [0xb7f24d10] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZNK4llvm3Use14getImpliedUserEv+0x7)[0xb477f357] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZNK4llvm3Use7getUserEv+0x18)[0xb477f3c8] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm20FunctionLoweringInfo3setERKNS_8FunctionERNS_15MachineFunctionEPNS_12SelectionDAGE+0x4e9)[0xb4b46169] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0x415)[0xb4c85945] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(+0x22a92b7)[0xb62e22b7] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x81)[0xb490d801] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x208)[0xb4739a98] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x42)[0xb4739b42] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x34a)[0xb473969a] /usr/lib/i386-linux-gnu/libLLVM-6.0.so.1(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x1f)[0xb473987f]
[llvm-bugs] [Bug 41891] New: after std::make_shared path-sensitive analysis stops
https://bugs.llvm.org/show_bug.cgi?id=41891
Bug ID: 41891
Summary: after std::make_shared path-sensitive analysis stops
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: plavsic.ognje...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
#include
int main()
{
auto b = std::make_shared(new int(10));
1/0;
}
After std::make_shared line of code, Static Analyzer won't throw Div by zero
warning. It works fine when i use std::make_unique, so it's really confusing.
--
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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41793, which changed state. Bug 41793 Summary: Please backport r360212 to 8.0 https://bugs.llvm.org/show_bug.cgi?id=41793 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 41793] Please backport r360212 to 8.0
https://bugs.llvm.org/show_bug.cgi?id=41793 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|r360212 |r360212 r360811 --- Comment #2 from Tom Stellard --- Merged: r360811 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41603, which changed state. Bug 41603 Summary: Please merge llvm r354846 for the 8.0.1 release https://bugs.llvm.org/show_bug.cgi?id=41603 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 41603] Please merge llvm r354846 for the 8.0.1 release
https://bugs.llvm.org/show_bug.cgi?id=41603 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r354846 |r354846 r360826 Status|NEW |RESOLVED --- Comment #1 from Tom Stellard --- Merged: r360826 -- 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 41883] Merge r360099 into the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41883 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r360099 |r360099 r360793 Status|NEW |RESOLVED --- Comment #2 from Tom Stellard --- Merged: r360793 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41883, which changed state. Bug 41883 Summary: Merge r360099 into the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=41883 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 40876] [aarch64] clang-cl 8.0rc2 generates unwind data that llvm-readelf cannot parse
https://bugs.llvm.org/show_bug.cgi?id=40876 Nathan Froyd changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Nathan Froyd --- Fixed in https://reviews.llvm.org/D61960 The original testcase now passes through `llvm-readelf -unwind` with no problems. -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41872, which changed state. Bug 41872 Summary: Merge r359569 into the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=41872 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 41872] Merge r359569 into the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41872 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|359569 |359569 r360801 Status|NEW |RESOLVED --- Comment #3 from Tom Stellard --- Merged: r360801 -- 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 41892] New: [X86][SSE] Failure to merge 2 x float stores to <2 x float> store
https://bugs.llvm.org/show_bug.cgi?id=41892
Bug ID: 41892
Summary: [X86][SSE] Failure to merge 2 x float stores to <2 x
float> store
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
https://godbolt.org/z/InfZZK
#include
void sum_pairs_128(__m128 f, float *p) {
p[0] = f[0] + f[1];
p[1] = f[2] + f[3];
}
clang -O3 -march=btver2
_Z13sum_pairs_128Dv4_fPf: # @_Z13sum_pairs_128Dv4_fPf
vhaddps %xmm0, %xmm0, %xmm0
vmovss %xmm0, (%rdi)
vextractps $1, %xmm0, 4(%rdi)
retq
would be better if we managed to merge to:
_Z13sum_pairs_128Dv4_fPf: # @_Z13sum_pairs_128Dv4_fPf
vhaddps %xmm0, %xmm0, %xmm0
vmovsd %xmm0, (%rdi)
retq
--
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 41890] error: assembler label '' can not be undefined
https://bugs.llvm.org/show_bug.cgi?id=41890 Reid Kleckner changed: What|Removed |Added CC||r...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r360818 --- Comment #1 from Reid Kleckner --- Thanks for the report, this should be fixed by r360818. -- 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 41818] Merge r355141 to 8.0.1
https://bugs.llvm.org/show_bug.cgi?id=41818 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r355141 |r355141 r360803 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Tom Stellard --- Merged: r360803 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41818, which changed state. Bug 41818 Summary: Merge r355141 to 8.0.1 https://bugs.llvm.org/show_bug.cgi?id=41818 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 41873] Merge r360674 into 8.0
https://bugs.llvm.org/show_bug.cgi?id=41873 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|360674 |360674 r360828 --- Comment #3 from Tom Stellard --- Merged: r360828 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41873, which changed state. Bug 41873 Summary: Merge r360674 into 8.0 https://bugs.llvm.org/show_bug.cgi?id=41873 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 41879] Please can we get a component for "wasm" under "lld"
https://bugs.llvm.org/show_bug.cgi?id=41879 Kristof Beyls changed: What|Removed |Added Resolution|--- |FIXED CC||kristof.be...@arm.com Status|NEW |RESOLVED --- Comment #1 from Kristof Beyls --- Hi Sam, I just created a wasm component under lld. I added yourself to the default cc list. If other people should be added too, let us know! Thanks, Kristof -- 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 41880] New: ~RTDyldMemoryManager should call deregisterEHFrames
https://bugs.llvm.org/show_bug.cgi?id=41880 Bug ID: 41880 Summary: ~RTDyldMemoryManager should call deregisterEHFrames Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: tneum...@users.sourceforge.net CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org The class RTDyldMemoryManager does not de-register the exception handling frames automatically when the memory manager is destroyed. This leads to crashes in C++ exception handling when an exception is thrown after an orc JIT instance is destroyed. The problem can be fixed trivially by calling deregisterEHFrames from the destructor of RTDyldMemoryManager. This is a regression introduced by llvm 8, and is probably an oversight caused by code movement. -- 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 31141] opt crashes while running "Loop Pass Manager" pass: Assertion `LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias sets"' failed
https://bugs.llvm.org/show_bug.cgi?id=31141 Hans Wennborg changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #8 from Hans Wennborg --- I also can't repro using the original source in the first comment. Let's close this. -- 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 31141] opt crashes while running "Loop Pass Manager" pass: Assertion `LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias sets"' failed
https://bugs.llvm.org/show_bug.cgi?id=31141 Florian Hahn changed: What|Removed |Added Resolution|WORKSFORME |FIXED Fixed By Commit(s)||360704 --- Comment #9 from Florian Hahn --- Yep r360704 solves this issue, by weakening the assertion to allow top-level loops to remain in LoopToAliasSetMap. We subsequently clear the map during finalization. There is not much else we can do with the current structure, as the removed loop object is already invalid when we call back to LICM to clean up the map. -- 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 41883] New: Merge r360099 into the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41883 Bug ID: 41883 Summary: Merge r360099 into the 8.0 branch Product: new-bugs Version: 8.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Please merge https://reviews.llvm.org/rL360099 into the 8.0 branch. This fixes bug 41417, which is about a fatal error "Bad machine code: Using an undefined physical register", when using -fstack-protector-strong on armv6. -- 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 10250 in oss-fuzz: llvm: Build failure
Comment #56 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c56 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-b5a0c634-8237-4b1a-b70b-a40f702750df.txt -- 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 41881] New: [DebugInfo@O2] SimplifyCFG sink splitting drops a variable location
https://bugs.llvm.org/show_bug.cgi?id=41881
Bug ID: 41881
Summary: [DebugInfo@O2] SimplifyCFG sink splitting drops a
variable location
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: wrong-debug
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: chackz0...@gmail.com, greg.bedw...@sony.com,
llvm-bugs@lists.llvm.org, orlando.hy...@sony.com,
paul.robin...@am.sony.com, stephen.to...@sony.com
Blocks: 38768
With llvm/clang r359863, running "clang -emit-llvm -O2 -g -S" on the code
below, the dbg.value representing the assignment of "local = q" is dropped by
SimplifyCFG. From the names of the basic blocks, it would appear to be the
SinkCommonCodeFromPredecessors function that does the dropping.
8<
volatile int g, *x;
int baz(int p, int q) {
int local;
local = p;
switch (g) {
case 1:
x[1] = local;
g += p;
break;
case 2:
x[1] += p;
break;
case 3:
local = q;
g++;
break;
}
return 4 + q;
}
>8
In this particular test case the impact of dropping the "local=q" assignment is
that the "local=p" assignment dominates all blocks, and an incorrect location
for "local" is produce in the "case 3" and exit block. (Didn't test this as far
as a debugger because I believe the error is fairly clear).
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
--
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 41882] New: Non-type template params with braced-init-list initializers are not supported
https://bugs.llvm.org/show_bug.cgi?id=41882 Bug ID: 41882 Summary: Non-type template params with braced-init-list initializers are not supported Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: blitzrak...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk template void f(); // expected expression One of the things nobody uses, it doesn't even have a TODO somewhere or a intentionally broken test AFAICT. We should probably start supporting this, with C++2a's class type non-type template parameters potentially making this kind of construct more popular. :) -- 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 41887] New: many check-fuzzer tests on linux when using the monorepo
https://bugs.llvm.org/show_bug.cgi?id=41887 Bug ID: 41887 Summary: many check-fuzzer tests on linux when using the monorepo Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I don't know if my machine is cursed in some way, but running "check-fuzzer" in a monorepo build on my google linux workstations leads to many test failures. Is it just me? It looks like they're hitting an internal ld.bfd error :-/ $ git clone --depth 1 https://github.com/llvm/llvm-project/ && mkdir llvm-project/build && cd llvm-project/build && cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld" ../llvm && ninja check-fuzzer [...] Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. FAIL: libFuzzer :: large.test (114 of 114) TEST 'libFuzzer :: large.test' FAILED Script: -- : 'RUN: at line 2'; /tmp/nanana/llvm-project/build/./bin/clang --driver-mode=g++ -std=c++11 -O2 -gline-tables-only -fsanitize=address,fuzzer -I/tmp/nanana/llvm-project/compiler-rt/lib/fuzzer -m32 /tmp/nanana/llvm-project/compiler-rt/test/fuzzer/LargeTest.cpp -o /tmp/nanana/llvm-project/build/projects/compiler-rt/test/fuzzer/I386DefaultLinuxConfig/Output/large.test.tmp-LargeTest : 'RUN: at line 3'; /tmp/nanana/llvm-project/build/projects/compiler-rt/test/fuzzer/I386DefaultLinuxConfig/Output/large.test.tmp-LargeTest -runs=1 : 'RUN: at line 4'; env ASAN_OPTIONS=handle_segv=0 /tmp/nanana/llvm-project/build/projects/compiler-rt/test/fuzzer/I386DefaultLinuxConfig/Output/large.test.tmp-LargeTest -runs=1 -lazy_counters=1 2>&1 | FileCheck /tmp/nanana/llvm-project/compiler-rt/test/fuzzer/large.test : 'RUN: at line 5'; /tmp/nanana/llvm-project/build/projects/compiler-rt/test/fuzzer/I386DefaultLinuxConfig/Output/large.test.tmp-LargeTest -runs=1 -lazy_counters=1 2>&1 | FileCheck /tmp/nanana/llvm-project/compiler-rt/test/fuzzer/large.test -- Exit Code: 1 Command Output (stderr): -- /usr/bin/ld: internal error ../../ld/ldlang.c 6635 clang-9: error: linker command failed with exit code 1 (use -v to see invocation) -- Testing Time: 18.57s Failing Tests (97): libFuzzer :: acquire-crash-state.test libFuzzer :: bad-strcmp.test libFuzzer :: bogus-initialize.test libFuzzer :: buffer-overflow-on-input.test libFuzzer :: caller-callee.test libFuzzer :: cleanse.test libFuzzer :: counters.test libFuzzer :: coverage.test libFuzzer :: cross_over.test libFuzzer :: cxxstring.test libFuzzer :: deep-recursion.test libFuzzer :: deprecated-instrumentation.test libFuzzer :: disable-leaks.test libFuzzer :: dso.test libFuzzer :: exit-report.test libFuzzer :: exit_on_src_pos.test libFuzzer :: extra-counters.test libFuzzer :: features_dir.test libFuzzer :: fork-sigusr.test libFuzzer :: fork-ubsan.test libFuzzer :: fork.test libFuzzer :: full-coverage-set.test libFuzzer :: fuzzer-alignment-assumption.test libFuzzer :: fuzzer-customcrossover.test libFuzzer :: fuzzer-customcrossoverandmutate.test libFuzzer :: fuzzer-custommutator.test libFuzzer :: fuzzer-dict.test libFuzzer :: fuzzer-dirs.test libFuzzer :: fuzzer-fdmask.test libFuzzer :: fuzzer-finalstats.test libFuzzer :: fuzzer-flags.test libFuzzer :: fuzzer-implicit-integer-sign-change.test libFuzzer :: fuzzer-implicit-signed-integer-truncation-or-sign-change.test libFuzzer :: fuzzer-implicit-signed-integer-truncation.test libFuzzer :: fuzzer-implicit-unsigned-integer-truncation.test libFuzzer :: fuzzer-leak.test libFuzzer :: fuzzer-oom-with-profile.test libFuzzer :: fuzzer-oom.test libFuzzer :: fuzzer-printcovpcs.test libFuzzer :: fuzzer-runs.test libFuzzer :: fuzzer-seed.test libFuzzer :: fuzzer-segv.test libFuzzer :: fuzzer-singleinputs.test libFuzzer :: fuzzer-threaded.test libFuzzer :: fuzzer-timeout.test libFuzzer :: fuzzer-ubsan.test libFuzzer :: initialize.test libFuzzer :: large.test libFuzzer :: len_control.test libFuzzer :: libcxx.test libFuzzer :: max-number-of-runs.test libFuzzer :: memcmp.test libFuzzer :: memcmp64.test libFuzzer :: merge-control-file.test libFuzzer :: merge-posix.test libFuzzer :: merge-sigusr.test libFuzzer :: merge.test libFuzzer :: minimize_crash.test libFuzzer :: minimize_two_crashes.test libFuzzer :: not-instrumented.test libFuzzer :: null-deref-on-empty.test libFuzzer :: null-deref.test
[llvm-bugs] [Bug 41886] New: -d/-r/-j should not require relocation sections be specified with -j
https://bugs.llvm.org/show_bug.cgi?id=41886 Bug ID: 41886 Summary: -d/-r/-j should not require relocation sections be specified with -j Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org llvm-objdump -d -r prints relocations inline with the disassembly as follows: C:\> llvm-objdump -d -r test.o Disassembly of section .text: 0400 .text: 400: e8 00 00 00 00callq 0 <.text+0x5> 0401: R_X86_64_PC32foo+1 0401: R_X86_64_GOT32 foo Disassembly of section .text2: 0401 .text2: 401: 90nop 402: e8 00 00 00 00callq 0 <.text2+0x6> 0402: R_X86_64_PLT32 foo+2 This is the same behaviour as GNU objdump. However, if you apply --section, the behaviour differs. --section for GNU objdump reduces the disassembly down to the listed sections, and prints all the relocations for those sections (note, the below output is approximate, and not exactly what GNU objdump prints, but is used for illustration purposes): C:\> objdump -d -r test.o --section .text Disassembly of section .text: 0400 .text: 400: e8 00 00 00 00callq 0 <.text+0x5> 0401: R_X86_64_PC32foo+1 //from .rela.text 0401: R_X86_64_GOT32 foo //from .rela2.text llvm-objdump only prints the relocations that come from the listed relocations: C:\> llvm-objdump -d -r test.o --section .text Disassembly of section .text: 0400 .text: 400: e8 00 00 00 00callq 0 <.text+0x5> // No relocations printed C:\> llvm-objdump -d -r test.o --section .text --rela.text Disassembly of section .text: 0400 .text: 400: e8 00 00 00 00callq 0 <.text+0x5> 0401: R_X86_64_PC32foo+1 //from .rela.text Intuitively, I didn't expect llvm-objdump to behave the way it does, even without coming from a GNU background. The behaviour is subtle and could easily break users. I think we should change the behaviour to match GNU and always print the relocations for the sections that are disassembled, not just the filtered set of relocations. -- 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 41890] New: error: assembler label '' can not be undefined
https://bugs.llvm.org/show_bug.cgi?id=41890
Bug ID: 41890
Summary: error: assembler label '' can not be undefined
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: tiagomacar...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
One of our open-source projects is failing to build with clang in 32 bits:
https://github.com/microsoft/wil/issues/7
I tracked down the minimal repro to be:
#include
void f()
{
__annotation(L"");
__int2c();
}
clang-cl.exe -c -m32 -Zi a.cpp
error: assembler label '' can not be undefined
error: assembler label '' can not be undefined
2 errors generated.
It works fine without the -m32 flag.
RNK take on the issue:
It looks like I misclassified the label as an EH_LABEL, and some pass is
dropping it. I'm not sure why the -m32 flag matters, but I don't think it will
be hard to fix.
--
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 41885] New: Variable with end part that is optimized out is printed incorrectly
https://bugs.llvm.org/show_bug.cgi?id=41885
Bug ID: 41885
Summary: Variable with end part that is optimized out is
printed incorrectly
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
When compiling the following example:
extern int ext;
volatile int global;
int main() {
int arr[32] = {123};
global = arr[0];
arr[0] = ext;
return 0;
}
with Clang (trunk) respectively GCC (8.3.0), you get different location
information about the optimized out elements at the end of arr:
$ clang -O3 -g opt-end.c -o clang.out
$ llvm-dwarfdump clang.out | grep -B2 -P "DW_AT_name.*arr"
DW_AT_location(0x
[0x00400480, 0x0040048a): DW_OP_constu
0x7b, DW_OP_stack_value, DW_OP_piece 0x4)
DW_AT_name("arr")
$ gcc-8 -O3 -g -gstrict-dwarf opt-end.c -o gcc.out
$ llvm-dwarfdump gcc.out | grep -A5 -P "DW_AT_name.*arr" | grep -vP
"DW_AT_decl|DW_AT_type"
DW_AT_name("arr")
DW_AT_location(0x
[0x04f0, 0x04fa): DW_OP_const1u
0x7b, DW_OP_stack_value, DW_OP_piece 0x4, DW_OP_piece 0x7c)
As seen, GCC emits an explicit empty location description piece which covers
the optimized out elements at the end of the array, whereas Clang does not emit
that.
This results in the elements being printed out with garbage data when debugging
the Clang binary in LLDB (7.0):
$ lldb-7 clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b main
Breakpoint 1: where = clang.out`main at opt-end.c:6, address =
0x00400480
(lldb) run
Process 22244 launched: '/home/edasten/upstream/master/clang.out' (x86_64)
Process 22244 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x00400480 clang.out`main at opt-end.c:6
3
4 int main() {
5int arr[32] = {123};
-> 6global = arr[0];
7arr[0] = ext;
8return 0;
9 }
(lldb) print arr
(int [32]) $0 = {
[0] = 123
[1] = 0
[2] = -1579873760
[3] = 32657
[4] = 32
[and so on...]
Also, in GDB (8.2.1) the elements are printed as instead of
:
(gdb) print arr
$1 = {123, }
It is unclear to me if the producer must cover the whole variable when emitting
composite location descriptions, or if the consumers should be able to handle
that, assuming that parts that are not explicitly covered are implicitly
covered by empty location descriptions. I did not manage to find anything in
the DWARF 4 and 5 standards that mandate the former (but I may of course have
missed it).
--
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 41866] Building with -D LLVM_ENABLE_PROJECTS='clang; lldb' on macOS errors for missing dependency target "cxx"
https://bugs.llvm.org/show_bug.cgi?id=41866 J. Ryan Stinnett changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||360756 --- Comment #2 from J. Ryan Stinnett --- Fixed by https://reviews.llvm.org/rL360756. -- 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 41884] New: [ARM] MachineScheduler can increase code size
https://bugs.llvm.org/show_bug.cgi?id=41884
Bug ID: 41884
Summary: [ARM] MachineScheduler can increase code size
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: david.gr...@arm.com
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org,
ties.st...@arm.com
When compiling Thumb2 code, the machine scheduler can end up increasing code
size.
If the scheduler uses more (virtual) registers, we will end up with more usage
of high registers, and be able to convert less instruction to T1.
Here is an example, showing the code it was producing:
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc %s -o - | FileCheck %s
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7em-arm-none-eabi"
%struct.a = type { i32, %struct.b*, i8, i8, i8, i8, i8*, %struct.b*, i16, i16,
i16, i16, i16, i16, i16, i16, i32, i32, i32, i32, i32, i32, i32 }
%struct.b = type { i8, i8, i8, i8, i32, i16, i16, i32, i32, i32, i32, [16 x
i8], [64 x i8], [128 x i8], i32, [68 x i8] }
define void @test(%struct.a* nocapture %dhcp, i16 zeroext %value) #0 {
; CHECK-LABEL: test:
; CHECK: @ %bb.0: @ %entry
; CHECK-NEXT:.save {r7, lr}
; CHECK-NEXT:push {r7, lr}
; CHECK-NEXT:ldrh r3, [r0, #20]
; CHECK-NEXT:ldr.w lr, [r0, #16]
; CHECK-NEXT:lsr.w r12, r1, #8
; CHECK-NEXT:adds r2, r3, #1
; CHECK-NEXT:strh r2, [r0, #20]
; CHECK-NEXT:add.w r2, lr, r3
; CHECK-NEXT:strb.w r12, [r2, #240]
; CHECK-NEXT:ldrh r2, [r0, #20]
; CHECK-NEXT:ldr.w r12, [r0, #16]
; CHECK-NEXT:adds r3, r2, #1
; CHECK-NEXT:strh r3, [r0, #20]
; CHECK-NEXT:add.w r0, r12, r2
; CHECK-NEXT:strb.w r1, [r0, #240]
; CHECK-NEXT:pop {r7, pc}
entry:
%shr = lshr i16 %value, 8
%conv1 = trunc i16 %shr to i8
%msg_out = getelementptr inbounds %struct.a, %struct.a* %dhcp, i32 0, i32 7
%0 = load %struct.b*, %struct.b** %msg_out, align 4
%options_out_len = getelementptr inbounds %struct.a, %struct.a* %dhcp, i32 0,
i32 8
%1 = load i16, i16* %options_out_len, align 4
%inc = add i16 %1, 1
store i16 %inc, i16* %options_out_len, align 4
%idxprom = zext i16 %1 to i32
%arrayidx = getelementptr inbounds %struct.b, %struct.b* %0, i32 0, i32 15,
i32 %idxprom
store i8 %conv1, i8* %arrayidx, align 1
%conv4 = trunc i16 %value to i8
%2 = load %struct.b*, %struct.b** %msg_out, align 4
%3 = load i16, i16* %options_out_len, align 4
%inc8 = add i16 %3, 1
store i16 %inc8, i16* %options_out_len, align 4
%idxprom9 = zext i16 %3 to i32
%arrayidx10 = getelementptr inbounds %struct.b, %struct.b* %2, i32 0, i32 15,
i32 %idxprom9
store i8 %conv4, i8* %arrayidx10, align 1
ret void
}
attributes #0 = { minsize optsize "target-cpu"="cortex-m4" }
For the moment, in D61882, we are disabling the machine scheduler in these
cases.
--
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
