[llvm-bugs] [Bug 42535] Atomics support missing on 32-bit SPARC
https://bugs.llvm.org/show_bug.cgi?id=42535 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |r...@gcc.gnu.org URL||https://reviews.llvm.org/D8 ||6621 --- Comment #2 from Rainer Orth --- Fixed for LLVM 12. -- 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 47487] New: support for GNU C label attributes
https://bugs.llvm.org/show_bug.cgi?id=47487
Bug ID: 47487
Summary: support for GNU C label attributes
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: ndesaulni...@google.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, isanb...@gmail.com,
jykni...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
https://gcc.gnu.org/onlinedocs/gcc/Label-Attributes.html#Label-Attributes
https://godbolt.org/z/Er3rP8
#include
int foo(void) {
asm goto ("some asm" : : : : NoError);
/* This branch (the fall-through from the asm) is less commonly used */
ErrorHandling:
__attribute__((cold, unused)); /* Semi-colon is required here */
printf("error\n");
return 0;
NoError:
printf("no error\n");
return 1;
}
clang:
warning: 'cold' attribute only applies to functions [-Wignored-attributes]
__attribute__((cold, unused)); /* Semi-colon is required here */
^
--
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 47485] [PowerPC] Merge fc2dac4116df into 11.0
https://bugs.llvm.org/show_bug.cgi?id=47485 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- This is new functionality, so I don't think we should merge it so late in the release process. -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47485, which changed state. Bug 47485 Summary: [PowerPC] Merge fc2dac4116df into 11.0 https://bugs.llvm.org/show_bug.cgi?id=47485 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47287, which changed state. Bug 47287 Summary: codeview assertion fails on lowerBound https://bugs.llvm.org/show_bug.cgi?id=47287 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 47287] codeview assertion fails on lowerBound
https://bugs.llvm.org/show_bug.cgi?id=47287 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Hans Wennborg --- (In reply to Alok Kumar Sharma from comment #13) > Please have a look at > https://reviews.llvm.org/D87406 That was committed in e45b0708ae81 and merged to 11.x in 29d700a8132088ee6320702b601c0479a710a3ec 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 47488] New: DFSan event_callbacks.c breaks with MemorySSA DSE
https://bugs.llvm.org/show_bug.cgi?id=47488 Bug ID: 47488 Summary: DFSan event_callbacks.c breaks with MemorySSA DSE Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: dfsan Assignee: unassignedb...@nondot.org Reporter: jeremy.morse.l...@gmail.com CC: florian_h...@apple.com, llvm-bugs@lists.llvm.org, masc...@google.com, sker...@chromium.org, vitalyb...@google.com After dead-store-elimination began using MemorySSA in fb109c42d9, a dfsan test has begun failing: compiler-rt/test/dfsan/event_callbacks.c As shown on this buildbot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/29539 Because the memcpy/memmove calls at the end of the main function are now optimised out. It looks like this is just a case of the test being optimised more than expected. Both DSE and dfsan are out of my area of expertise, so I'm marking the test XFail for now, CCing recent dfsan authors and Florian. -- 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 47489] New: JSON Compilation Database docs unclear on meaning of "arguments"
https://bugs.llvm.org/show_bug.cgi?id=47489
Bug ID: 47489
Summary: JSON Compilation Database docs unclear on meaning of
"arguments"
Product: Documentation
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: General docs
Assignee: unassignedb...@nondot.org
Reporter: matth...@stdin.nl
CC: llvm-bugs@lists.llvm.org
The Clang docs about compilation_commands.json [1] show two alternatives for
specifying the compile command: A single string shell-escaped compiler
commandline, and a pre-split arguments version.
[1]: https://clang.llvm.org/docs/JSONCompilationDatabase.html
However:
- There is no example for the "arguments" version.
- It is unclear where the command goes exactly. Should you specify the
command (ARGV[0]) in "commands" and any arguments (ARGV[1+]) in
"arguments"? Or should "arguments" contain the entire split
commandline and should "commands" be omitted? Looking at
implementations, it seems to be the latter.
I would propose making this more explicit. For example, maybe using the
following text and example (I'm not 100% sure this is correct, so feedback
welcome).
> Same example using arguments:
> [
> { "directory": "/home/user/llvm/build",
> "arguments": ["/usr/bin/clang++", "-Irelative", "-DSOMEDEF=With spaces,
> quotes and \-es.", "-c", "-o", "file.o", "file.cc",
> "file": "file.cc" },
> ...
> ]
> - arguments: The compile command executed as list of strings. This includes
>the compiler command itself, along with all its arguments. Each element of
> the
>array is used as-is, without any further quoting other than the
> JSON-quoting.
The remark "Either arguments or command is required." should probably be
moved to below the enumeration of fields. Also, maybe it should be
clarified if it is acceptable to specify both (I think it is)? Also, I
think that "arguments" should be preferred (less ambiguity with
quoting), but is there a case for specifying "command" in addition" to
"arguments" for incomplete parsers (i.e. maybe "arguments" was added
later)?
Note that the quoting and backslash in the example does not seem to be
entirely sensible, but that's being discussed in
https://bugs.llvm.org/show_bug.cgi?id=21505 so I just left the example
as-is here.
--
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 47490] New: Request to cherry-pick Neon bfloat16 mangling fix onto LLVM 11 branch
https://bugs.llvm.org/show_bug.cgi?id=47490 Bug ID: 47490 Summary: Request to cherry-pick Neon bfloat16 mangling fix onto LLVM 11 branch Product: clang Version: 11.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: sander.desma...@arm.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 46725 Apologies for requesting this so late in the release cycle, but would it be possible to cherry-pick cabd60c26b5df34f096a5a915bde3b1d8ee1 onto the LLVM 11 release branch? It's a small fix for the mangling of bfloat16 NEON vectors that is important for ABI compatibility. I think it's low risk in terms of breakage and it applies cleanly to the release branch (this has verified by cherry-picking it on the release branch and running make check all). Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46725 [Bug 46725] [meta] 11.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 47490] Request to cherry-pick Neon bfloat16 mangling fix onto LLVM 11 branch
https://bugs.llvm.org/show_bug.cgi?id=47490 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- Okay, pushed to 11.x as bff8d98129e8512ce9dcaed04e49c4f32f3a7e71. Please let me know if there are any follow-ups. -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47490, which changed state. Bug 47490 Summary: Request to cherry-pick Neon bfloat16 mangling fix onto LLVM 11 branch https://bugs.llvm.org/show_bug.cgi?id=47490 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 47491] New: 8-byte loop not vectorized
https://bugs.llvm.org/show_bug.cgi?id=47491
Bug ID: 47491
Summary: 8-byte loop not vectorized
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
void pr(char* restrict r, char* restrict a){
#pragma clang loop vectorize(enable)
for (int i = 0; i < 8; i++){
r[i] += a[i];
}
}
Clang -O3:
pr: # @pr
mov al, byte ptr [rsi]
add byte ptr [rdi], al
mov al, byte ptr [rsi + 1]
add byte ptr [rdi + 1], al
mov al, byte ptr [rsi + 2]
add byte ptr [rdi + 2], al
mov al, byte ptr [rsi + 3]
add byte ptr [rdi + 3], al
mov al, byte ptr [rsi + 4]
add byte ptr [rdi + 4], al
mov al, byte ptr [rsi + 5]
add byte ptr [rdi + 5], al
mov al, byte ptr [rsi + 6]
add byte ptr [rdi + 6], al
mov al, byte ptr [rsi + 7]
add byte ptr [rdi + 7], al
ret
ICC or GCC -O3 (without any pragma):
pr:
movq xmm1, QWORD PTR [rdi] #3.9
movq xmm0, QWORD PTR [rsi] #3.17
paddb xmm1, xmm0#3.9
movq QWORD PTR [rdi], xmm1 #3.9
ret
--
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 47492] New: Bad machine code: No live subrange at use after Greedy Register Allocator
https://bugs.llvm.org/show_bug.cgi?id=47492 Bug ID: 47492 Summary: Bad machine code: No live subrange at use after Greedy Register Allocator Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: jay.f...@gmail.com CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com Created attachment 23947 --> https://bugs.llvm.org/attachment.cgi?id=23947&action=edit test case With the attached test case I get: $ ~/llvm-debug/bin/llc -march=amdgcn -verify-machineinstrs ge.mir -start-before=greedy [...] *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 844B undef %433.sub0:vreg_128 = COPY %432.sub0:vreg_128 - operand 1: %432.sub0:vreg_128 - interval:%432 [256r,844r:0) 0@256r L0030 [256r,844r:0) 0@256r weight:3.066802e-03 - at: 844B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 908B undef %449.sub0:vreg_128 = COPY %448.sub0:vreg_128 - operand 1: %448.sub0:vreg_128 - interval:%448 [320r,908r:0) 0@320r L0030 [320r,908r:0) 0@320r weight:3.066802e-03 - at: 908B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 920B undef %453.sub0:vreg_128 = COPY %452.sub0:vreg_128 - operand 1: %452.sub0:vreg_128 - interval:%452 [336r,920r:0) 0@336r L0030 [336r,920r:0) 0@336r weight:3.079268e-03 - at: 920B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 972B undef %465.sub0:vreg_128 = COPY %464.sub0:vreg_128 - operand 1: %464.sub0:vreg_128 - interval:%464 [384r,972r:0) 0@384r L0030 [384r,972r:0) 0@384r weight:3.066802e-03 - at: 972B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 984B undef %469.sub0:vreg_128 = COPY %468.sub0:vreg_128 - operand 1: %468.sub0:vreg_128 - interval:%468 [400r,984r:0) 0@400r L0030 [400r,984r:0) 0@400r weight:3.079268e-03 - at: 984B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 1036Bundef %481.sub0:vreg_128 = COPY %480.sub0:vreg_128 - operand 1: %480.sub0:vreg_128 - interval:%480 [464r,1036r:0) 0@464r L0030 [464r,1036r:0) 0@464r weight:3.117284e-03 - at: 1036B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 1048Bundef %485.sub0:vreg_128 = COPY %484.sub0:vreg_128 - operand 1: %484.sub0:vreg_128 - interval:%484 [480r,1048r:0) 0@480r L0030 [480r,1048r:0) 0@480r weight:3.130165e-03 - at: 1048B *** Bad machine code: No live subrange at use *** - function:zextload_global_v64i16_to_v64i64 - basic block: %bb.0 (0x946b398) [0B;2848B) - instruction: 1100Bundef %497.sub0:vreg_128 = COPY %496.sub0:vreg_128 - operand 1: %496.sub0:vreg_128 - interval:%496 [544r,1100r:0) 0@544r L0030 [544r,1100r:0) 0@544r weight:3.169456e-03 - at: 1100B LLVM ERROR: Found 8 machine code errors. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. The test case comes from test/CodeGen/AMDGPU/global-extload-i16.ll compiled with D87502 applied. -- 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 47493] New: Missed cases by Memory SSA DSE, works with legacy DSE
https://bugs.llvm.org/show_bug.cgi?id=47493
Bug ID: 47493
Summary: Missed cases by Memory SSA DSE, works with legacy DSE
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
define void @killed_by_load(i8* %a, i8* %b) {
bb0:
store i8 undef, i8* %a
br label %bb1
bb1:
%tmp = load i8, i8* %b
store i8 undef, i8* %a
ret void
}
-basic-aa -dse -enable-dse-memoryssa=false
define void @killed_by_load(i8* %a, i8* %b) {
store i8 undef, i8* %a, align 1
br label %bb1
bb1: ; preds = %bb0
store i8 undef, i8* %a, align 1
ret void
}
-basic-aa -dse -enable-dse-memoryssa=true
define void @killed_by_load(i8* %a, i8* %b) {
store i8 undef, i8* %a, align 1
br label %bb1
bb1: ; preds = %bb0
%tmp = load i8, i8* %b, align 1
store i8 undef, i8* %a, align 1
ret void
}
--
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 47494] New: [IR] Suboptimal vector code
https://bugs.llvm.org/show_bug.cgi?id=47494
Bug ID: 47494
Summary: [IR] Suboptimal vector code
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
void test(int* restrict r, int* restrict a){
for (int i = 0; i < 16; i++){
r[i] += r[i+1];
}
}
Clang -O3 -mavx2:
test: # @test
vmovdqu ymm0, ymmword ptr [rdi]
vmovdqu ymm1, ymmword ptr [rdi + 32]
vperm2i128 ymm2, ymm0, ymm1, 33# ymm2 = ymm0[2,3],ymm1[0,1]
vpalignrymm2, ymm2, ymm0, 4 # ymm2 =
ymm0[4,5,6,7,8,9,10,11,12,13,14,15],ymm2[0,1,2,3],ymm0[20,21,22,23,24,25,26,27,28,29,30,31],ymm2[16,17,18,19]
vpaddd ymm0, ymm0, ymm2
vmovdqu ymmword ptr [rdi], ymm0
vmovdqu xmm0, xmmword ptr [rdi + 48]
vpshufd xmm2, xmm0, 249 # xmm2 = xmm0[1,2,3,3]
vpinsrd xmm2, xmm2, dword ptr [rdi + 64], 3
vpalignrxmm0, xmm0, xmmword ptr [rdi + 32], 4 # xmm0 =
mem[4,5,6,7,8,9,10,11,12,13,14,15],xmm0[0,1,2,3]
vinserti128 ymm0, ymm0, xmm2, 1
vpaddd ymm0, ymm1, ymm0
vmovdqu ymmword ptr [rdi + 32], ymm0
vzeroupper
ret
ICC -O3 -mavx2:
test:
vmovdqu ymm0, YMMWORD PTR [rdi] #4.10
vmovdqu ymm2, YMMWORD PTR [32+rdi]#4.10
vpadddymm1, ymm0, YMMWORD PTR [4+rdi] #4.10
vpadddymm3, ymm2, YMMWORD PTR [36+rdi] #4.10
vmovdqu YMMWORD PTR [rdi], ymm1 #4.10
vmovdqu YMMWORD PTR [32+rdi], ymm3#4.10
vzeroupper #6.1
ret #6.1
--
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 47493] Missed cases by Memory SSA DSE, works with legacy DSE
https://bugs.llvm.org/show_bug.cgi?id=47493 David Bolvansky changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from David Bolvansky --- Ok, resolved. -- 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 47495] New: Wsizeof-array-div false positive when divisor is sizeof reference type
https://bugs.llvm.org/show_bug.cgi?id=47495
Bug ID: 47495
Summary: Wsizeof-array-div false positive when divisor is
sizeof reference type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: sir.vences...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hi,
I found a bug where clang reports a false positive here:
int my_function()
{
int array[10];
const int narray = sizeof(array)/sizeof(int&);
return narray;
}
clang output:
:4:37: warning: expression does not compute the number of elements in
this array; element type is 'int', not 'int &' [-Wsizeof-array-div]
const int narray = sizeof(array)/sizeof(int&);
~ ^
:3:9: note: array 'array' declared here
int array[10];
^
:4:37: note: place parentheses around the 'sizeof(int &)' expression to
silence this warning
const int narray = sizeof(array)/sizeof(int&);
^
1 warning generated.
The standard says this about sizeof: "When applied to a reference or a
reference type, the result is the size of the referenced type."
I'm getting this even on the trunk version on godbolt.com
(https://godbolt.org/z/Pb4adf).
--
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 47496] New: Regression in use of conditional unreachable's in LLVM
https://bugs.llvm.org/show_bug.cgi?id=47496 Bug ID: 47496 Summary: Regression in use of conditional unreachable's in LLVM Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: curde...@gmail.com CC: llvm-bugs@lists.llvm.org That's a regression of the issue fixed in #810, as commented there: https://bugs.llvm.org/show_bug.cgi?id=810#c15. It seems that the current trunk version of clang (as of 2020-09-02) does not optimize away the call to f1 in test2 (nb. clang 9 and 10 did optimize it). See: https://godbolt.org/z/YK13j1. -- 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 25360 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !Result || (LHS.isSentinel() && LHS.Inst == RHS.Inst) || getHashValueImpl(LHS) =
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25360 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !Result || (LHS.isSentinel() && LHS.Inst == RHS.Inst) || getHashValueImpl(LHS) = https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25360#c1 ClusterFuzz testcase 6271494379012096 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009100622:202009110620 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 47488] DFSan event_callbacks.c breaks with MemorySSA DSE
https://bugs.llvm.org/show_bug.cgi?id=47488 Matt Morehouse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matt Morehouse --- Fixed the test in 2df6efedef5c7647f966ba238a2901eb4b98204d. -- 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 47497] New: vector (iterator, iterator) constructor doesn't deduce second arg
https://bugs.llvm.org/show_bug.cgi?id=47497
Bug ID: 47497
Summary: vector (iterator,iterator) constructor doesn't deduce
second arg
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: logan.r.smi...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following code is rejected by libc++ because the second iterator argument
to vector(iterator, iterator) is not deduced (https://godbolt.org/z/q8f9Y7):
#include
#include
#include
int main() {
std::vector v({}, std::istream_iterator{});
}
The the following code, however, is accepted (https://godbolt.org/z/nM4Yh4):
#include
#include
#include
int main() {
std::vector v;
v.assign({}, std::istream_iterator{});
}
I believe this to be a conformance bug.
I stumbled on this in my own code when I noticed that a typo in the following
code was being accepted:
std::vector v(other.cbegin(), other.end()); // note .end(), not .cend()
Since the second argument is not deduced, and the first argument is a const
iterator, the second argument is implicitly converted to a const iterator. This
is a symptom of the same issue, though I think this particular case could
arguably be considered a conforming extension.
--
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 47498] New: [MemorySSA] PHI translations leads to wrong defining access for load in loop
https://bugs.llvm.org/show_bug.cgi?id=47498
Bug ID: 47498
Summary: [MemorySSA] PHI translations leads to wrong defining
access for load in loop
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: florian_h...@apple.com
CC: llvm-bugs@lists.llvm.org
For the IR below, it seems like PHI translation leads to the wrong defining
access for `%l.1 = load i32, i32* %p.1, align 4`. MemorySSA uses the call to
@init outside the loop as defining access.
But unless I am missing something, I think it should be `; 4 =
MemoryPhi({bb,1},{loop.1.latch,3})`.
Consider the following execution sequence:
1. loop.1.header reads from %tmp[1]...%tmp[11].
2. execute storebb, which writes %tmp[11]
3. goto loop.1.latch
4. execute loop.1.header again, which reads from %tmp[1]...%tmp[11]. That
includes the value stored in %storebb, so the defining access should be `3 =
MemoryPhi...`
https://godbolt.org/z/7srs1s
This leads to DSE+MemorySSA to determine `store i32 10, i32* %p.1, align 4` is
never read and can be removed. I suspect this is causing the following failure:
http://lab.llvm.org:8011/builders/clang-s390x-linux-lnt/builds/20711
IR:
declare i1 @should_exit(i32) readnone
declare void @init([32 x i32]*)
define i32 @blam(i32 %arg, i32 %arg1) #0 {
bb:
%tmp = alloca [32 x i32], align 16
call void @init([32 x i32]* %tmp)
br label %loop.1.header
loop.1.header:
%iv = phi i64 [ 0, %bb ], [ %iv.next, %loop.1.latch ]
%iv.next = add nuw nsw i64 %iv, 1
%p.1 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.next
%l.1 = load i32, i32* %p.1, align 4
%tmp244 = icmp ult i64 %iv, 10
br i1 %tmp244, label %loop.1.latch, label %storebb
loop.1.latch:
%ec = call i1 @should_exit(i32 %l.1)
br i1 %ec, label %exit, label %loop.1.header
storebb:
%iv.add2 = add nuw nsw i64 %iv, 2
%p.2 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.add2
%l.2 = load i32, i32* %p.2, align 4
store i32 10, i32* %p.1, align 4
br label %loop.1.latch
exit:
ret i32 10
}
opt -analyze -print-memoryssa
define i32 @blam(i32 %arg, i32 %arg1) {
bb:
%tmp = alloca [32 x i32], align 16
; 1 = MemoryDef(liveOnEntry)
call void @init([32 x i32]* %tmp)
br label %loop.1.header
loop.1.header:; preds = %loop.1.latch, %bb
; 4 = MemoryPhi({bb,1},{loop.1.latch,3})
%iv = phi i64 [ 0, %bb ], [ %iv.next, %loop.1.latch ]
%iv.next = add nuw nsw i64 %iv, 1
%p.1 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.next
; MemoryUse(1) MayAlias
%l.1 = load i32, i32* %p.1, align 4
%tmp244 = icmp ult i64 %iv, 10
br i1 %tmp244, label %loop.1.latch, label %storebb
loop.1.latch: ; preds = %storebb,
%loop.1.header
; 3 = MemoryPhi({loop.1.header,4},{storebb,2})
%ec = call i1 @should_exit(i32 %l.1)
br i1 %ec, label %exit, label %loop.1.header
storebb: ; preds = %loop.1.header
%iv.add2 = add nuw nsw i64 %iv, 2
%p.2 = getelementptr inbounds [32 x i32], [32 x i32]* %tmp, i64 0, i64
%iv.add2
; MemoryUse(1) MayAlias
%l.2 = load i32, i32* %p.2, align 4
; 2 = MemoryDef(4)
store i32 10, i32* %p.1, align 4
br label %loop.1.latch
exit: ; preds = %loop.1.latch
ret i32 10
}
--
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 47499] New: __unaligned extension inconsistent behaviour with C and C++
https://bugs.llvm.org/show_bug.cgi?id=47499
Bug ID: 47499
Summary: __unaligned extension inconsistent behaviour with C
and C++
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: rofir...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
struct Foo {
unsigned long x;
};
void foo(__unaligned struct Foo* out){
out->x = 5;
}
Emits this in C (which is the expected behaviour)
%struct.Foo = type { i64 }
define dso_local void @foo(%struct.Foo* nocapture %0) local_unnamed_addr #0 {
%2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 0
store i64 5, i64* %2, align 1, !tbaa !2
ret void
}
but this in C++ which does not honour the qualifier
%struct.Foo = type { i64 }
define dso_local void @_Z3fooPU11__unaligned3Foo(%struct.Foo* nocapture %0)
local_unnamed_addr #0 {
%2 = getelementptr inbounds %struct.Foo, %struct.Foo* %0, i64 0, i32 0
store i64 5, i64* %2, align 8, !tbaa !2
ret void
}
We want both languages agree. I suggest we bring the current behaviour in C to
C++.
--
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 47501] New: [InstCombine] Unreported IR changes from InstCombine
https://bugs.llvm.org/show_bug.cgi?id=47501 Bug ID: 47501 Summary: [InstCombine] Unreported IR changes from InstCombine Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Created attachment 23949 --> https://bugs.llvm.org/attachment.cgi?id=23949&action=edit instcombine.ll With expensive checks enabled: $ opt -instcombine -S instcombine.ll Pass modifies its input and doesn't report it: Combine redundant instructions -- 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 47502] New: Cannot add mutually recursive functions into RefSCC
https://bugs.llvm.org/show_bug.cgi?id=47502
Bug ID: 47502
Summary: Cannot add mutually recursive functions into RefSCC
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: aeuba...@google.com
CC: alina.sbir...@gmail.com, htmldevelo...@gmail.com,
johan...@jdoerfert.de, llvm-bugs@lists.llvm.org,
modoca...@gmail.com
When adding mutually recursive (ref-wise) functions to a CGSCC via
LazyCallGraph::addNewFunctionIntoRefSCC(), the following assert triggers:
Assertion failed: !lookup(F) && "node already exists", file
../../llvm/lib/Analysis/LazyCallGraph.cpp, line 1598
This is because addNewFunctionIntoRefSCC() calls createNode(), which populates
the edges for that node and creates nodes for any functions it references by
calling get(). Let's say we want to call addNewFunctionIntoRefSCC() on two
newly created and mutually recursive functions. After the first
addNewFunctionIntoRefSCC(), it has created two nodes, one for each of the newly
added functions. Then in the second call to addNewFunctionIntoRefSCC(), it
calls createNode() on the second function, but the node was already created via
a call to get() previously, so the assert triggers.
https://reviews.llvm.org/D72025 and https://reviews.llvm.org/D70927 introduced
addNewFunctionIntoSCC() and addNewFunctionIntoRefSCC().
Reproducible via unittests with the diff in CGSCCCPassManagerTest.cpp below:
```
@@ -1753,11 +1753,29 @@ TEST_F(CGSCCPassManagerTest, TestInsertionOfNewRefSCC)
{
Type::getInt8PtrTy(F.getContext()),
"f.ref", &*F.begin()->begin());
+ // Create mutually recursive functions 'h1' and 'h2'.
+ auto *H1 = Function::Create(F.getFunctionType(), F.getLinkage(),
+ F.getAddressSpace(), "h1",
F.getParent());
+ auto *H2 = Function::Create(F.getFunctionType(), F.getLinkage(),
+ F.getAddressSpace(), "h2",
F.getParent());
+ BasicBlock *H1BB =
+ BasicBlock::Create(F.getParent()->getContext(), "entry", H1);
+ BasicBlock *H2BB =
+ BasicBlock::Create(F.getParent()->getContext(), "entry", H2);
+ (void)CallInst::Create(H2, {}, "", H1BB);
+ ReturnInst::Create(H1->getContext(), H1BB);
+ (void)CallInst::Create(H1, {}, "", H2BB);
+ ReturnInst::Create(H2->getContext(), H2BB);
+
+ CG.addNewFunctionIntoRefSCC(*H1, C.getOuterRefSCC());
+ CG.addNewFunctionIntoRefSCC(*H2, C.getOuterRefSCC());
+
+ F.getParent()->dump();
ASSERT_NO_FATAL_FAILURE(
updateCGAndAnalysisManagerForCGSCCPass(CG, C, N, AM, UR, FAM))
<< "Updating the call graph with a demoted, self-referential "
- "call edge 'f -> f', and a newly inserted ref edge 'f -> g',
"
- "caused a fatal failure";
+ "call edge 'f -> f', a newly inserted ref edge 'f -> g', and
"
+ "mutually recursive h1 <-> h2 caused a fatal failure";
}
```
$ ./build/debug/obj/llvm/unittests/Analysis/AnalysisTests.exe
--gtest_filter='*TestInsertionOfNew*' --gtest_catch_exceptions=0
Note: Google Test filter = *TestInsertionOfNew*
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from CGSCCPassManagerTest
[ RUN ] CGSCCPassManagerTest.TestInsertionOfNewRefSCC
Starting llvm::Module pass manager run.
Starting CGSCC pass manager run.
Assertion failed: !lookup(F) && "node already exists", file
../../llvm/lib/Analysis/LazyCallGraph.cpp, line 1598
--
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 47503] New: [CodeGenPrepare] Unreported IR changes in OptimizeExtractBits
https://bugs.llvm.org/show_bug.cgi?id=47503 Bug ID: 47503 Summary: [CodeGenPrepare] Unreported IR changes in OptimizeExtractBits Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Created attachment 23950 --> https://bugs.llvm.org/attachment.cgi?id=23950&action=edit OptimizeExtractBits.ll With expensive checks enabled: opt -codegenprepare -S OptimizeExtractBits.ll Pass modifies its input and doesn't report it: CodeGen Prepare The reproducer is not quite as reduced as it could be, but I need to get to a stopping point for the week. The `MadeChange =` should be `MadeChange |=` at https://github.com/llvm/llvm-project/blob/06e356c81e0fce90c9a21f9f5fb7567efa51ee0f/llvm/lib/CodeGen/CodeGenPrepare.cpp#L1847 This apparently dates back to LLVM 3.5: https://github.com/llvm/llvm-project/commit/d069f6393a7c I haven't tested, but by inspection, this other use of `MadeChange =` also looks suspicious: https://github.com/llvm/llvm-project/blob/06e356c81e0fce90c9a21f9f5fb7567efa51ee0f/llvm/lib/CodeGen/CodeGenPrepare.cpp#L1153 -- 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 44223] LLVM CommandLine category registration seems to have initialization order issues (triggers ASAN initialization-order-fiasco)
https://bugs.llvm.org/show_bug.cgi?id=44223 Ben Vanik changed: What|Removed |Added Resolution|WONTFIX |--- CC||benva...@google.com Status|RESOLVED|REOPENED --- Comment #3 from Ben Vanik --- Correct; this has nothing to do with MLIR static dialect registration and is specifically about LLVM's `CommandLineParser::registerCategory` (which is using static initialization). -- 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 47090] icmp gives inconsistent result for unnamed functions
https://bugs.llvm.org/show_bug.cgi?id=47090 Eli Friedman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||efrie...@quicinc.com --- Comment #4 from Eli Friedman --- d751f86 -- 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 45158] __is_constructible intrinsic does not SFINAE on default member initializers
https://bugs.llvm.org/show_bug.cgi?id=45158 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Richard Smith --- Re comment#2, that's not the same as this issue. Default member initializers are not parsed until the closing brace of the outermost enclosing class they're nested within -- the default member initializer for A is not parsed until we reach the end of DataWithStruct. As a consequence (in particular, because we can't compute the exception specification for the default constructor until we've parsed the default member initializers, and in general we never form a call to a function until after we know its exception specification), default construction of an `A` fails in the context of the type of DataWithStruct::t. So that's not a bug. Given the original problem is also not a bug, I'm going to resolve this INVALID. We can reopen it or open a new bug if the committee decides to do something SFINAE-like for default member initializers. -- 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
