[llvm-bugs] [Bug 51279] New: llvm-objcopy: for WASM object format support --localize-hidden (and maybe --redefine-sym)
https://bugs.llvm.org/show_bug.cgi?id=51279 Bug ID: 51279 Summary: llvm-objcopy: for WASM object format support --localize-hidden (and maybe --redefine-sym) Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: vadimkanto...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org This would help linking WASM-object files with same-named functions. Usecase: I'm trying to link in one busybox-like executable various WASM-compiled TexLive binaries that have same-named functions that are implemented slightly differently. Original usecase description in Emscripten repo: https://github.com/emscripten-core/emscripten/issues/12167#issuecomment-731779128 -- 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 51280] New: Backport lldb AArch64 memory tagging commands changes to 13.x branch
https://bugs.llvm.org/show_bug.cgi?id=51280 Bug ID: 51280 Summary: Backport lldb AArch64 memory tagging commands changes to 13.x branch Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: david.spick...@linaro.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Currently 13.x has a "memory tag read" command and half the supporting code for "memory tag write". Backporting the following patches would complete the tag write command, and the basic memory tagging feature set for lldb 13. 6a7a2ee8161da84d9a58a88b497b0b47c8df99f3 https://reviews.llvm.org/D105182 - Memory tag write command 6eded00e0c6b4e06225df74292c078030556b8ce https://reviews.llvm.org/D105183 - Memory tag write "--end-addr" option d510b5f199d6e7a3062b5a6ea43181c4cc00a605 https://reviews.llvm.org/D105178 - Annotate synchronous tag faults 555cd03193c9c098d787bec93eadfe43b179db9c https://reviews.llvm.org/D104914 - Correct memtags packets type field format 98b5659b53ff93f3b68e48ea28ec54081196ae3b https://reviews.llvm.org/D106880 - Mark mismatched tags in "memory tag read" output Ok to cherry pick these to the branch? Also I'd like to add these features to the lldb release notes. Can I do that directly or should I put up a phabricator review for it first? -- 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 51171] SIGSEGV at DeduceTemplateArgumentsByTypeMatch
https://bugs.llvm.org/show_bug.cgi?id=51171 Ivan Murashko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ivan Murashko --- Resolved by https://reviews.llvm.org/D106583 -- 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 51281] New: [X86][AVX] Incorrect decoding of constant vector data from X86ISD::SUBV_BROADCAST_LOAD nodes
https://bugs.llvm.org/show_bug.cgi?id=51281
Bug ID: 51281
Summary: [X86][AVX] Incorrect decoding of constant vector data
from X86ISD::SUBV_BROADCAST_LOAD nodes
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: llvm-...@redking.me.uk
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Internal fuzz tests have found an issue that appeared after rGc8472db0a88701.
The more aggressive creation of X86ISD::SUBV_BROADCAST_LOAD nodes has exposed
an existing bug with incorrect constant decoding in
getTargetConstantBitsFromNode if its referencing a constant pool entry larger
than the subvector size.
define <16 x float> @shuffc(<8 x float> %a0) {
%shuffle = shufflevector <8 x float> %a0, <8 x float> , <16 x i32>
ret <16 x float> %shuffle
}
https://c.godbolt.org/z/b9W3xKe1e
codegen (same for trunk and 12.x):
shuffc: # @shuffc
vextractf128xmm1, ymm0, 1
vperm2f128 ymm3, ymm0, ymm0, 1 # ymm3 = ymm0[2,3,0,1]
vshufps xmm2, xmm0, xmm1, 49# xmm2 = xmm0[1,0],xmm1[3,0]
vshufps xmm1, xmm2, xmm1, 210 # xmm1 = xmm2[2,0],xmm1[1,3]
vmovsldup xmm2, xmm0 # xmm2 = xmm0[0,0,2,2]
vblendpsymm0, ymm3, ymm0, 66# ymm0 =
ymm3[0],ymm0[1],ymm3[2,3,4,5],ymm0[6],ymm3[7]
vpermilps ymm0, ymm0, ymmword ptr [rip + .LCPI0_1] # ymm0 =
ymm0[3,3,1,1,6,7,6,4]
vinsertf128 ymm1, ymm2, xmm1, 1
vblendpsymm1, ymm1, ymmword ptr [rip + .LCPI0_0], 141 # ymm1 =
mem[0],ymm1[1],mem[2,3],ymm1[4,5,6],mem[7]
ret
trunk constant table:
.LCPI0_0:
.long 0x # float 0
.zero 4
.long 0x3eb5dbc6 # float 0.355192363
.long 0x3eb5dbc6 # float 0.355192363
.zero 4
.long 0x3eb5dbc6 # float 0.355192363
.zero 4
.zero 4
12.x constant table:
.LCPI0_0:
.long 0x # float 0
.zero 4
.long 0x3eb5dbc6 # float 0.355192363
.long 0x3eb5dbc6 # float 0.355192363
.zero 4
.long 0x3eb5dbc6 # float 0.355192363
.long 0x3eb5dbc6 # float 0.355192363
.long 0x3eb5dbc6 # float 0.355192363
I'm currently working on a patch.
--
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 51275] clang crashes on valid code at -Os and above: Assertion `!empty()' failed (SLP vectorizer)
https://bugs.llvm.org/show_bug.cgi?id=51275 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||c2deb2afafee991c06cc9 Status|NEW |RESOLVED --- Comment #4 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rGc2deb2afafee991c06cc9 I don't think the bug was visible in the 13.0 release, so I'm resolving as fixed. Please reopen if that's not correct. -- 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 36695 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: Index < Length && "Invalid index!"
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-30 Type: Bug New issue 36695 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: Index < Length && "Invalid index!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36695 Detailed Report: https://oss-fuzz.com/testcase?key=5451798977576960 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Index < Length && "Invalid index!" llvm::AArch64TargetLowering::lowerInterleavedStore InterleavedAccess::runOnFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5451798977576960 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 48102] NULL is not defined for standards prior to 2.0
https://bugs.llvm.org/show_bug.cgi?id=48102 Justas Janickas changed: What|Removed |Added Status|NEW |RESOLVED CC||justas.janic...@arm.com Resolution|--- |FIXED --- Comment #2 from Justas Janickas --- Fixed by https://reviews.llvm.org/rG5c63bf3abdc7 -- 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 51282] New: Type deduction loses alignment
https://bugs.llvm.org/show_bug.cgi?id=51282
Bug ID: 51282
Summary: Type deduction loses alignment
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: erich.ke...@intel.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Example:
https://godbolt.org/z/q7W5csMnc
typedef signed char int8x8_t __attribute__ ((aligned(16)));
int8x8_t foo();
void baz(const int8x8_t &a);
void bar()
{
const int8x8_t a = foo();
baz(a);
alignas(16) const auto b = foo();
baz(b);
}
The warning is:
:11:7: warning: passing 1-byte aligned argument to 16-byte aligned
parameter 1 of 'baz' may result in an unaligned pointer access
[-Walign-mismatch]
baz(b);
I debugged this down to the beginning of
SemaTemplateDeduction.cpp::DeduceTemplateArgumentsByTypeMatch. The
S.Context.getCanonicalType(ArgIn) line loses the typedef (which seems
intentional, based on the comment above it).
However, this also loses the alignment attached to the typedef.
Note that the 'alignas' is also lost, but is not necessarily part of this
example. With/without it, we still get the warning because 'b' doesn't pick up
the alignment.
I would think about just fixing up the alignment in
DeduceTemplateArgumentsByTypeMismatch, but I suspect there needs to be a bigger
holistic approach to 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 38831] AArch64 assembly gives error in one case but not in other equivalent case.
https://bugs.llvm.org/show_bug.cgi?id=38831 Victor Campos changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||victor.cam...@arm.com --- Comment #3 from Victor Campos --- Cannot reproduce on ce52e0339f0ae1e7ac915f041b3f4d32081f648e -- 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 36608 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 36608 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36608#c1 ClusterFuzz testcase 6123294251810816 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202107290602:202107300611 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 35786 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in clang::Lexer::Lex
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 35786 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in clang::Lexer::Lex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35786#c1 ClusterFuzz testcase 4696891127365632 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202107290602:202107300611 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 51283] New: llvm-omp-device-info not build when using RUNTIMES instead of PROJECTS
https://bugs.llvm.org/show_bug.cgi?id=51283 Bug ID: 51283 Summary: llvm-omp-device-info not build when using RUNTIMES instead of PROJECTS Product: OpenMP Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: jo...@udel.edu CC: llvm-bugs@lists.llvm.org When building OpenMP with the -DLLVM_ENABLED_RUNTIMES=openmp, instead of -DOPENMP_ENABLED_PROJECTS=openmp, the llvm-omp-device-info tool is not compiled or installed. This is because the runtimes compilation process removes the -DLLVM_BUILD_TOOLS flag from the second cmake call. -- 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 36700 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: getValueKind() == VK_LValue
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-30 Type: Bug New issue 36700 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: getValueKind() == VK_LValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36700 Detailed Report: https://oss-fuzz.com/testcase?key=5130811241922560 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getValueKind() == VK_LValue clang::Expr::ClassifyImpl clang::Expr::isModifiableLvalue Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011230606:202011240611 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5130811241922560 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] Issue 36704 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!"
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-2021-07-30 Type: Bug New issue 36704 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36704 Detailed Report: https://oss-fuzz.com/testcase?key=6045756715827200 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" llvm::Constant::isNotMinSignedValue llvm::Negator::visitImpl Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202008270608:202008280607 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6045756715827200 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 51284] New: Backport fix to internalization in the Attributor.
https://bugs.llvm.org/show_bug.cgi?id=51284 Bug ID: 51284 Summary: Backport fix to internalization in the Attributor. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenMP Assignee: unassignedclangb...@nondot.org Reporter: hube...@ornl.gov CC: llvm-bugs@lists.llvm.org Blocks: 51236 The previous implementation of function internalization had an issue where the internal copies of functions were called by external versions. This didn't cleanly separate the internal and external code paths which resulted in IPO optimizations incorrectly mixing the two. This resulted in remarks being duplicated for any internalized function if they were enabled among other problems. This was reviewd in https://reviews.llvm.org/D106931 and committed as adbaa39dfce7a8361d89b6a3b382fd8f50b94727. A follow-up commit is necessary to fix a test that was failing on one of the built-bots: 97851a08e2684388dec24fbe46818704052f9dbe. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=51236 [Bug 51236] [meta] 13.0.0 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 51285] New: LLVM optimization and code generation for if-else chains vs ternary chains vs a switch
https://bugs.llvm.org/show_bug.cgi?id=51285
Bug ID: 51285
Summary: LLVM optimization and code generation for if-else
chains vs ternary chains vs a switch
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: l...@rifkin.dev
CC: llvm-bugs@lists.llvm.org
I'm looking at an example of three equivalent functions implemented with
if-else chains, ternary chains, and a switch. LLVM is not compiling them
equivalently: https://godbolt.org/z/3PE59hKdx.
For some reason the if-else chain and switch compile equivalently but the
ternary is missing a fold.
I don't think it's idealistic to say these should compile equivalently - if
someone told me to prefer one over the other for performance reasons I'd
dismiss it as a micro-optimization.
GCC struggles with this as well, I've just filed a bug report for GCC.
Interestingly GCC does the ternary and switch well but struggles with the
if-else chain.
As for the ternary case, the switch and if-else chain compile as such:
define dso_local i32 @_Z3fooi(i32 %0) local_unnamed_addr #0 {
; if %0 - 1 < 4 { return %0 } else { return -1 }
%2 = add i32 %0, -1
%3 = icmp ult i32 %2, 4
%4 = select i1 %3, i32 %0, i32 -1
ret i32 %4
}
Whereas the ternary chain compiles as
define dso_local i32 @_Z5func2i(i32 %0) local_unnamed_addr #0 {
; if %0 - 1 < 3 {
; return %0
; } else {
; if %0 == 4 {
; return 4
; } else {
; return -1
; }
; }
%2 = add i32 %0, -1
%3 = icmp ult i32 %2, 3
%4 = icmp eq i32 %0, 4
%5 = select i1 %4, i32 4, i32 -1
%6 = select i1 %3, i32 %0, i32 %5
ret i32 %6
}
Evidently missing a fold.
One last thing to note: clang trunk compiles the ternary chain better than
clang 12 (which has leaves branch in 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 51286] New: Regression: Missed fold for x * 0
https://bugs.llvm.org/show_bug.cgi?id=51286
Bug ID: 51286
Summary: Regression: Missed fold for x * 0
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: l...@rifkin.dev
CC: llvm-bugs@lists.llvm.org
Clang trunk is not generating optimal code for a (very poor) multiplication
routine https://godbolt.org/z/GrjMhsTcv.
int mul(int x, int y) {
int p = 0;
while(x--) p += y;
return p;
}
Should compile to:
mul(int, int):
mov eax, edi
imuleax, esi
ret
And it does in clang 12 but not in clang trunk.
If I'm not mistaken it appears a select i1 (icmp eq i32 %x, 0), i32 0, i32 (mul
i32 %x, %y) -> mul i32 %x, %y fold is not firing.
--
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 51287] New: [clang][avr] clang crashed when compiling cpp program
https://bugs.llvm.org/show_bug.cgi?id=51287
Bug ID: 51287
Summary: [clang][avr] clang crashed when compiling cpp program
Product: clang
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: powerman...@163.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
clang++ test.cc -O3 -Wall --target=avr -mmcu=atmega328 -S
```
// test.cc
volatile char *p = (volatile char *) 0x4000;
class test {
int v;
public:
test(int q): v(q) {}
int get(void) { return v; }
~test() { *p = v; }
};
test obj(4);
```
clang crashed with info
```
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: ./bin/clang++ a.cc -O3 -Wall --target=avr
-mmcu=atmega328 -S
1. parser at end of file
2. a.cc:11:6: LLVM IR generation of declaration 'obj'
3. a.cc:11:6: Generating code for declaration 'obj'
#0 0x5610f8f6a5cf PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x5610f8f68490 llvm::sys::CleanupOnSignal(unsigned long)
(./bin/clang+++0x2084490)
#2 0x5610f8ec1b58 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7f19678ad980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#4 0x5610f93afd9d (anonymous
namespace)::AVRTargetCodeGenInfo::getGlobalVarAddressSpace(clang::CodeGen::CodeGenModule&,
clang::VarDecl const*) const TargetInfo.cpp:0:0
#5 0x5610f92f32fa
clang::CodeGen::CodeGenModule::GetGlobalVarAddressSpace(clang::VarDecl const*)
(./bin/clang+++0x240f2fa)
#6 0x5610f9313bc6
clang::CodeGen::CodeGenModule::GetOrCreateLLVMGlobal(llvm::StringRef,
llvm::Type*, unsigned int, clang::VarDecl const*,
clang::CodeGen::ForDefinition_t) (./bin/clang+++0x242fbc6)
#7 0x5610f9314919
clang::CodeGen::CodeGenModule::CreateRuntimeVariable(llvm::Type*,
llvm::StringRef) (./bin/clang+++0x2430919)
#8 0x5610f9384963 (anonymous
namespace)::ItaniumCXXABI::registerGlobalDtor(clang::CodeGen::CodeGenFunction&,
clang::VarDecl const&, llvm::FunctionCallee, llvm::Constant*)
ItaniumCXXABI.cpp:0:0
#9 0x5610f95256d9 EmitDeclDestroy(clang::CodeGen::CodeGenFunction&,
clang::VarDecl const&, clang::CodeGen::ConstantAddress) CGDeclCXX.cpp:0:0
#10 0x5610f952601e
clang::CodeGen::CodeGenFunction::GenerateCXXGlobalVarDeclInitFunc(llvm::Function*,
clang::VarDecl const*, llvm::GlobalVariable*, bool) (./bin/clang+++0x264201e)
#11 0x5610f95265ab
clang::CodeGen::CodeGenModule::EmitCXXGlobalVarDeclInitFunc(clang::VarDecl
const*, llvm::GlobalVariable*, bool) (./bin/clang+++0x26425ab)
#12 0x5610f9312b92
clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*,
bool) (./bin/clang+++0x242eb92)
#13 0x5610f932d8f5
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (./bin/clang+++0x24498f5)
#14 0x5610f932e13b
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
(./bin/clang+++0x244a13b)
#15 0x5610f9333d2d
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.5272)
CodeGenModule.cpp:0:0
#16 0x5610f9e7fe91 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
ModuleBuilder.cpp:0:0
#17 0x5610f9e73cd2
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) crtstuff.c:0:0
#18 0x5610fab0bc74 clang::ParseAST(clang::Sema&, bool, bool)
(./bin/clang+++0x3c27c74)
#19 0x5610f9e7dda2 clang::CodeGenAction::ExecuteAction()
(./bin/clang+++0x2f99da2)
#20 0x5610f9856c21 clang::FrontendAction::Execute()
(./bin/clang+++0x2972c21)
#21 0x5610f97f4292
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(./bin/clang+++0x2910292)
#22 0x5610f9922c93
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(./bin/clang+++0x2a3ec93)
#23 0x5610f7d2700c cc1_main(llvm::ArrayRef, char const*,
void*) (./bin/clang+++0xe4300c)
#24 0x5610f7d233dd ExecuteCC1Tool(llvm::SmallVectorImpl&)
driver.cpp:0:0
#25 0x5610f969f8a5 void llvm::function_ref::callback_fn
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#26 0x5610f8ec2143
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref)
(./bin/clang+++0x1fde143)
#27 0x5610f96a195e
clang::driver::CC1Command::Execute(llvm::ArrayRef
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const (./bin/clang+++0x27bd95e)
#28 0x5610f967739a
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&,
clang::driver::Command const*&) const (./bin/clang+++0x279339a)
#29 0x5610f9677eef
clang::driver::Compilation::ExecuteJobs(cla
[llvm-bugs] [Bug 51288] New: Convert mov and shr to shrx in loops constrained by retirement rate
https://bugs.llvm.org/show_bug.cgi?id=51288
Bug ID: 51288
Summary: Convert mov and shr to shrx in loops constrained by
retirement rate
Product: new-bugs
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: t...@lipcon.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This input file:
#include
#include
struct Foo {
uint64_t v;
std::pair Get() { return {v & 0x, v >> 32}; }
};
void Process(Foo* f, uint32_t* dst, int n) {
#pragma unroll
for (int i = 0; i < n; i++) {
auto [mask, idx] = f[i].Get();
dst[idx] |= mask;
}
}
Generates some assembly where the core of the loop has the following sequence:
movq24(%rdi,%rax,8), %r9
movq%r9, %rcx
shrq$32, %rcx
orl %r9d, (%rsi,%rcx,4)
When compiling with bmi2 support, it would instead be slightly faster to store
the constant 32 into a register and use shrx to combine the copy of %r9 into
%rcx with a shift.
Generated version:
https://bit.ly/2WzH8Pj
Preferred version (~saving half a cycle per unrolled-by-4 loop):
https://bit.ly/3jaXBBh
--
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 36715 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::isTemplateName
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-31 Type: Bug New issue 36715 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::isTemplateName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36715 Detailed Report: https://oss-fuzz.com/testcase?key=5316754661310464 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcfeec6fe8 Crash State: clang::Sema::isTemplateName clang::Parser::ParseOptionalCXXScopeSpecifier clang::Parser::TryAnnotateCXXScopeToken Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202105130607:202105140620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5316754661310464 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
