[llvm-bugs] [Bug 50183] Preferred canonicalization - select-of-idx vs select-of-gep ?
https://bugs.llvm.org/show_bug.cgi?id=50183 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||d561b6fbdbe6d1da05fd92003a4 ||ac1e37bf4b8bc Resolution|--- |FIXED Status|NEW |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 51087] New: Extraneous enum record in DWARF with type units
https://bugs.llvm.org/show_bug.cgi?id=51087
Bug ID: 51087
Summary: Extraneous enum record in DWARF with type units
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: wrong-debug
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: apra...@apple.com, dblai...@gmail.com,
llvm-bugs@lists.llvm.org, paul.robin...@am.sony.com
This PR is a summary of an interesting scenario I've run into, where using type
units increases binary size, although only compared to constructor homing
de-duplication of types. Take a look at this reproducer, compiled with the
following flags using main / ee8da6369225f4:
clang++ test.cpp -o test.o -c -g -O2 -fdebug-types-section -gdwarf-5
8<
class fudge {
public:
enum blah {
a = 1,
b = 2
};
blah baz;
fudge() { }
};
fudge bar;
>8
If you take a look with llvm-dwarfdump at the output file, there are type units
for "fudge" and "blah" as expected, and for the "bar variable:
0x001e: DW_TAG_variable
DW_AT_name ("bar")
DW_AT_type (0x0029 "class ")
DW_AT_external (true)
DW_AT_decl_file ("test.cpp")
DW_AT_decl_line (13)
DW_AT_location (DW_OP_addrx 0x0)
0x0029: DW_TAG_class_type
DW_AT_declaration (true)
DW_AT_signature (0x1c93e96b85e3f5c8)
0x0032: DW_TAG_enumeration_type
DW_AT_declaration (true)
DW_AT_signature (0x9b7ed24ce9445148)
To me, the DW_TAG_enumeration_type in the class definition is unexpected, as
the "fudge" type unit completely describes the contents of the class. Nothing
in the DWARF refers to the enum type. To me, this seems like an inefficiency.
Not shown is the larger project I've looked at, where there are enough
redundant child-enum-DIEs and child-class-DIEs in each class DIE to add a few
Mb of .debug_info (out of ~160Mb of .debug_info). The net effect is that
running with "-Xclang -fuse-ctor-homing -fdebug-types-section" is larger than
just using "-Xclang -fuse-ctor-homing"
--
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 51088] New: Target mapping error for target_struct_map.4.c Case 1
https://bugs.llvm.org/show_bug.cgi?id=51088 Bug ID: 51088 Summary: Target mapping error for target_struct_map.4.c Case 1 Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: pro...@itc.rwth-aachen.de CC: llvm-bugs@lists.llvm.org Created attachment 25022 --> https://bugs.llvm.org/attachment.cgi?id=25022&action=edit Reduced code from the Examples document The first case in the code example target_struct_map.4.c provided in the upcoming OpenMP Examples document leads to a runtime error. CUDA error: an illegal memory access was encountered Libomptarget error: Call to targetDataEnd failed, abort target. The code runs fine, when removing mapping of S1.p. Removing S1.p from the mapping would actually be an error, because there should be no pointer attachment without mapping S1.p. -- 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 51089] New: Target mapping error for target_struct_map.4.c Case 2
https://bugs.llvm.org/show_bug.cgi?id=51089 Bug ID: 51089 Summary: Target mapping error for target_struct_map.4.c Case 2 Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: pro...@itc.rwth-aachen.de CC: llvm-bugs@lists.llvm.org Created attachment 25023 --> https://bugs.llvm.org/attachment.cgi?id=25023&action=edit Reduced code from the Examples document The second case in the code example target_struct_map.4.c provided in the upcoming OpenMP Examples document leads to a runtime error. Libomptarget message: explicit extension not allowed: host address specified is 0x7ffd5c65cf38 (24 bytes), but device allocation maps to host at 0x7ffd5c65cf48 (8 bytes) The mapping of S2.p[:n] at the target data construct should only map the array, but not the pointer S2.p. The map clause at the target construct should create the struct with elements a,b,p and perform the pointer attachment for S2.p -- 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 51090] New: Dead Code Elimination Regression
https://bugs.llvm.org/show_bug.cgi?id=51090
Bug ID: 51090
Summary: Dead Code Elimination Regression
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: theodoros.theodori...@inf.ethz.ch
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
extern void foo(void);
int a;
short b(unsigned short c, int d) {
return d < 0 || c > (600 >> d) ? c : c << d;
}
int main() {
char f;
int g = 300;
while (a) {
f = g;
if (!b(f, 2)) {
foo();
g = 0;
}
}
return 0;
}
commit 1a02aaeaa4f8675490da38ee8cb0d4a6d39815dd introduced a regression
(for Target: x86_64-unknown-linux-gnu).
The generated asm (clang -S -c -O3) for main before that commit was:
main: # @main
.Lmain$local:
.cfi_startproc
# %bb.0:
cmpl$0, .La$local(%rip)
je .LBB1_2
.p2align4, 0x90
.LBB1_1:# =>This Inner Loop Header: Depth=1
jmp .LBB1_1
.LBB1_2:
xorl%eax, %eax
retq
.Lfunc_end1:
.size main, .Lfunc_end1-main
.cfi_endproc
and after:
main: # @main
.Lmain$local:
.cfi_startproc
# %bb.0:
pushq %rax
.cfi_def_cfa_offset 16
movl.La$local(%rip), %eax
testl %eax, %eax
je .LBB1_5
# %bb.1:
movl$300, %edx # imm = 0x12C
jmp .LBB1_2
.p2align4, 0x90
.LBB1_4:# in Loop: Header=BB1_2 Depth=1
testl %eax, %eax
je .LBB1_5
.LBB1_2:# =>This Inner Loop Header: Depth=1
movsbl %dl, %ecx
movzwl %cx, %esi
cmpl$151, %esi
setb%cl
addb%cl, %cl
shll%cl, %esi
testw %si, %si
jne .LBB1_4
# %bb.3:# in Loop: Header=BB1_2 Depth=1
callq foo
xorl%edx, %edx
movl.La$local(%rip), %eax
jmp .LBB1_4
.LBB1_5:
xorl%eax, %eax
popq%rcx
.cfi_def_cfa_offset 8
retq
.Lfunc_end1:
.size main, .Lfunc_end1-main
.cfi_endproc
--
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 51091] New: Failure to widen loads from wider dereferenceable pointers
https://bugs.llvm.org/show_bug.cgi?id=51091
Bug ID: 51091
Summary: Failure to widen loads from wider dereferenceable
pointers
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: a.bat...@hotmail.com, craig.top...@gmail.com,
lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
If we have generated this:
define float @Dot01(float* dereferenceable(16) %a0, float* dereferenceable(16)
%a1) {
%bcx01 = bitcast float* %a0 to <2 x float>*
%bcy01 = bitcast float* %a1 to <2 x float>*
%x01 = load <2 x float>, <2 x float>* %bcx01, align 4
%y01 = load <2 x float>, <2 x float>* %bcy01, align 4
%mul01 = fmul <2 x float> %x01, %y01
%mul0 = extractelement <2 x float> %mul01, i32 0
%mul1 = extractelement <2 x float> %mul01, i32 1
%dot01 = fadd float %mul0, %mul1
ret float %dot01
}
llc -mcpu=znver2
Dot01:
vmovsd (%rdi), %xmm0 # xmm0 = mem[0],zero
vmovsd (%rsi), %xmm1 # xmm1 = mem[0],zero
vmulps %xmm1, %xmm0, %xmm0
vmovshdup %xmm0, %xmm1# xmm1 = xmm0[1,1,3,3]
vaddss %xmm1, %xmm0, %xmm0
retq
As we know that the pointers at (%rdi) and (%rsi) are both dereferenceable
across the full 16 bytes - why can't we load full float4 loads, which would let
us fold at least one of the loads:
Dot01:
vmovups (%rdi), %xmm0
vmulps(%rsi), %xmm0, %xmm0
vmovshdup %xmm0, %xmm1# xmm1 = xmm0[1,1,3,3]
vaddss%xmm1, %xmm0, %xmm0
retq
(I'm not sure if we can perform this generally in DAG or VectorCombine or
whether we should just handle it inside x86's EltsFromConsecutiveLoads or
something).
--
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 51082] link error when overriding common symbols with weak symbols in library
https://bugs.llvm.org/show_bug.cgi?id=51082 Fangrui Song changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Fangrui Song --- Fixed by https://reviews.llvm.org/D105945 (target: 13.0.0) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51092] New: Duplicate select instruction causing one use check failure
https://bugs.llvm.org/show_bug.cgi?id=51092
Bug ID: 51092
Summary: Duplicate select instruction causing one use check
failure
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
nikita@gmail.com, spatel+l...@rotateright.com
https://godbolt.org/z/4avqKsT4x
struct PayLoad
{
unsigned short data[3];
};
void sort(PayLoad* pData, int lo, int hi, int ishi)
{
if (ishi)
{
pData->data[hi]++;
}
else
{
pData->data[lo]++;
}
}
%struct.PayLoad = type { [3 x i16] }
define void @_Z4sortP7PayLoadiii(%struct.PayLoad* nocapture %0, i32 %1, i32 %2,
i32 %3) {
%5 = icmp eq i32 %3, 0
%6 = sext i32 %1 to i64
%7 = getelementptr inbounds %struct.PayLoad, %struct.PayLoad* %0, i64 0, i32
0, i64 %6
%8 = sext i32 %2 to i64
%9 = getelementptr inbounds %struct.PayLoad, %struct.PayLoad* %0, i64 0, i32
0, i64 %8
%10 = select i1 %5, i16* %7, i16* %9
%11 = select i1 %5, i16* %7, i16* %9
%12 = load i16, i16* %10, align 2, !tbaa !3
%13 = add i16 %12, 1
store i16 %13, i16* %11, align 2, !tbaa !3
ret void
}
I'm currently investigating supporting select(gep,gep) folding for geps with >
2 operands, but we fail the one use check on this reduced test case as we end
up with the same select instruction twice which never get merged.
Should these be merged or not?
--
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 51085] error caused by inlining function while compiling with -O3.
https://bugs.llvm.org/show_bug.cgi?id=51085 David Blaikie changed: What|Removed |Added CC||dblai...@gmail.com Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 18259] -Wimplicit-fallthrough gets confused by a non-case label in a switch
https://bugs.llvm.org/show_bug.cgi?id=18259 Kees Cook changed: What|Removed |Added CC||keesc...@chromium.org Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kees Cook --- This was fixed in Clang 3.3: https://godbolt.org/z/s3KPK6vrx -- 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 51093] New: clang::format::WhitespaceManager::alignConsecutiveAssignments() crash
https://bugs.llvm.org/show_bug.cgi?id=51093 Bug ID: 51093 Summary: clang::format::WhitespaceManager::alignConsecutiveAssi gnments() crash Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: sbauer...@hotmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Running into a crash with the main branch. Tried commits 50cf0a1d1ae48bd0397b41a400e01c62975b6706a and 18c19414eb70578d4c487d6f4b0f438aead71d6a -- CRASH $ clang-format -style=file -i format_this.c clang-format: /source/repos/llvm-project/clang/lib/Format/WhitespaceManager.cpp:367: void clang::format::AlignTokenSequence(unsigned int, unsigned int, unsigned int, F&&, llvm::SmallVector&) [with F = clang::format::WhitespaceManager::alignConsecutiveAssignments()::&]: Assertion `Shift >= 0' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: clang-format -style=file -i format_this.c Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): clang-format[0x4c9ef9] clang-format[0x4c9fb0] clang-format[0x4c7fa6] clang-format[0x4c994c] /lib64/libpthread.so.0(+0xf630)[0x7efc99a40630] /lib64/libc.so.6(gsignal+0x37)[0x7efc98b5f387] /lib64/libc.so.6(abort+0x148)[0x7efc98b60a78] /lib64/libc.so.6(+0x2f1a6)[0x7efc98b581a6] /lib64/libc.so.6(+0x2f252)[0x7efc98b58252] clang-format[0x5d22be] clang-format[0x5cfcf1] clang-format[0x5d0298] clang-format[0x5ce592] clang-format[0x5cd5a0] clang-format[0x54afa5] clang-format[0x58ce4f] clang-format[0x54fdb3] clang-format[0x557bbe] clang-format[0x5565df] clang-format[0x555714] clang-format[0x5678ad] clang-format[0x5502a9] clang-format[0x550577] clang-format[0x406969] clang-format[0x4075ff] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7efc98b4b555] clang-format[0x404f7e] Aborted (core dumped) -- 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 18259] -Wimplicit-fallthrough gets confused by a non-case label in a switch
https://bugs.llvm.org/show_bug.cgi?id=18259 Richard Smith changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Richard Smith --- I think this was broken, not fixed, in Clang 3.3: we should warn here, but don't. -- 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 51094] New: -Wimplicit-fallthrough needlessly warning about unreachable code
https://bugs.llvm.org/show_bug.cgi?id=51094 Bug ID: 51094 Summary: -Wimplicit-fallthrough needlessly warning about unreachable code Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: keesc...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk There are some places in the kernel where the "fallthrough;" annotation is used after a portion of code that may get elided at build time: case 1: if (something || !IS_ENALBED(CONFIG_SOMETHING)) return blah; fallthrough; case 2: This looks like: case 1: fallthrough; case 2: And a warning is generated: warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough] But isn't a useful warning in this case, and should likely be silenced or adjust to not warn where there was actually code there before getting elided. At the least, this warning would be best moved to a separate flag so it can be disabled on kernel builds (i.e. GCC does not warn about these cases). Some specific examples: https://github.com/ClangBuiltLinux/continuous-integration2/runs/3058126539?check_suite_focus=true#step:5:120 https://github.com/ClangBuiltLinux/continuous-integration2/runs/3058126329?check_suite_focus=true#step:5:92 -- 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 50433] wasm32: v128.load8_lane not used with equivalent pattern
https://bugs.llvm.org/show_bug.cgi?id=50433 Thomas Lively changed: What|Removed |Added Fixed By Commit(s)||970e0900104d6f67a9c15fa9c91 ||3cf3eeba5d06a Resolution|--- |FIXED CC||tliv...@google.com Status|NEW |RESOLVED --- Comment #2 from Thomas Lively --- Thanks, Alex! Fixed in https://reviews.llvm.org/rG970e0900104d6f67a9c15fa9c913cf3eeba5d06a -- 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 50473] [ARM] RELA relocations not resolved correctly for 32-bit little endian ARM
https://bugs.llvm.org/show_bug.cgi?id=50473 Wolfgang Pieb changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Wolfgang Pieb --- Fixed with https://github.com/llvm/llvm-project/commit/d1116697be059350a5b04d1af29e2d454afda746 -- 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 51095] New: Variable not globalized on the device when nested inside parallel region.
https://bugs.llvm.org/show_bug.cgi?id=51095 Bug ID: 51095 Summary: Variable not globalized on the device when nested inside parallel region. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenMP Assignee: a.bat...@hotmail.com Reporter: hube...@ornl.gov CC: jdoerf...@anl.gov, llvm-bugs@lists.llvm.org In this example (https://godbolt.org/z/W4WMPr5xq) the variable `x` is shared between all the threads by writing its pointer to a global value that is read by all the threads. This should be legal according to OpenMP, but when the variable is placed directly inside the parallel region, rather than inside of a function that's called in parallel, it will not be globalized. When I compile and the first version on my nvptx64 machine I get the following: $ clang++ version1.cpp -fopenmp-targets=nvptx64 -fopenmp $ ./a.out Thread 0: 1 Thread 1: 1 Thread 2: 1 ... Thread 125: 1 Thread 126: 1 Thread 127: 1 The second version where `x` is directly in the parallel region gives me this: $ clang++ version1.cpp -fopenmp-targets=nvptx64 -fopenmp $ ./a.out Thread 0: 0 Thread 1: 1 Thread 2: 2 ... Thread 125: 125 Thread 126: 126 Thread 127: 127 A call to `__kmpc_alloc_shared` is not inserted for the variable `x` in the second version, leading to the value not being sharable between the threads. -- 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 50999] [clang-format] AlwaysBreakAfterReturnType does not work with K&R C function definitions
https://bugs.llvm.org/show_bug.cgi?id=50999 Owen Pan changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||rG58494c856a15 -- 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 50973] [SimpleLoopUnswitch] Assertion `!NodePtr->isKnownSentinel()' failed when catchswitch BB is cloned
https://bugs.llvm.org/show_bug.cgi?id=50973 Heejin Ahn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||5366de7375e653998ff80c3c6cb ||dfa4f9b9046e3 -- 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 51096] New: powerpc: wrong floating point constant emitted in constant pool
https://bugs.llvm.org/show_bug.cgi?id=51096 Bug ID: 51096 Summary: powerpc: wrong floating point constant emitted in constant pool Product: libraries Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: bug...@aerifal.cx CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Created attachment 25024 --> https://bugs.llvm.org/attachment.cgi?id=25024&action=edit test case This test case comes from musl libc's floor.c, adapted to be a standalone file. It was found to be miscompiled, first for powerpcspe, by libc-test, but the same turns out to happen on normal non-spe powerpc as well. The failing tests included floor(-0x1.fp-1) and a number of other calls with small-magnitude arguments. In the code path for small exponent (integer part zero), the ternary gets emitted as a branch and conditional load from a constant pool, but instead of having -1.0 in the constant pool for the true branch, +1.0 is there. I tried minifying the test case further, but most changes I tried produced bit arithmetic instead of the constant pool loads, and masked the problem. Putting (double)-1 instead of -1 in the ternary, so as not to rely on promotion of the integer result to double, also masks the problem. I'm not sure if the description of this bug is correct. It's possible that some earlier transformation introduces the wrong value, instead of it happening when emitting the rodata. I checked other targets that use loads from a constant pool for floating point values like this, including armhf, s390x, and mips, and they were not affected, so the issue seems to be powerpc-backend-specific. -- 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 51097] New: GVN crashes (possible cache bug)
https://bugs.llvm.org/show_bug.cgi?id=51097 Bug ID: 51097 Summary: GVN crashes (possible cache bug) Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: jdoerf...@anl.gov CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org, wmo...@mit.edu Created attachment 25025 --> https://bugs.llvm.org/attachment.cgi?id=25025&action=edit dominance issue (reduced, still large) The two attachments crash with different errors after gvn. One is reduced by llvm-reduce from the other. Manually trimming some otherwise trivial control flow, e.g. the following empty diamond: A: br undef, B, C, B: br J C: br J J: br ... will hide the bug. -- 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 51098] New: WebAssembly doesn't always generate f64x2.convert_low_i32x4_s/u as expected
https://bugs.llvm.org/show_bug.cgi?id=51098 Bug ID: 51098 Summary: WebAssembly doesn't always generate f64x2.convert_low_i32x4_s/u as expected Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: s...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 25027 --> https://bugs.llvm.org/attachment.cgi?id=25027&action=edit Sample .ll file to show the problem When generating wasm code with simd128 enabled, the LLVM backend only seems to generate the f64x2.convert_low_i32x4_s (or _u) instructions if the input vector is *exactly* 4 wide; if the input vector is a multiple of 4 (e.g. 8), the generated code isn't a sequence of f64x2.convert_low_i32x4_s/u instructions, but a sequence of scalarized calls to extract_lane+convert_i64_s+replace_lane. To see this behavior: ``` llc -march=wasm32 test_op_f64x2_convert_low_i32x4_s_0.ll -o - -O3 -mattr=+sign-ext,+simd128,+nontrapping-fptoint ``` -- 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 39251] Return of structs in C calling convention is done on stack, incompatible with avr-gcc usually using registers
https://bugs.llvm.org/show_bug.cgi?id=39251 Ben Shi changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #7 from Ben Shi --- fixed in https://reviews.llvm.org/rGc94c8d8b5d999c97ea424b35a1cb540d2a1d3bc6 https://github.com/llvm/llvm-project/commit/c94c8d8b5d999c97ea424b35a1cb540d2a1d3bc6 -- 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 51099] New: NVPTX backend crash due to address space inference failure
https://bugs.llvm.org/show_bug.cgi?id=51099 Bug ID: 51099 Summary: NVPTX backend crash due to address space inference failure Product: Projects Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Stacker Assignee: unassignedb...@nondot.org Reporter: happybaoli...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 25028 --> https://bugs.llvm.org/attachment.cgi?id=25028&action=edit testcase makes NVPTX backend crash I'm trying to compile CUDA code using llvmorg-11.0.0-rc6. NVPTX backend crash when using the following command to compile PTX code: llc -march=nvptx temp-cuda-nvptx64-nvidia-cuda-sm_50.ll -O3 testcase is attached. -- 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 36201 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-15 Type: Bug New issue 36201 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36201 Detailed Report: https://oss-fuzz.com/testcase?key=547690490144 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isValueDependent() && "Expression evaluator can't be called on a dependent expr clang::Expr::isConstantInitializer clang::Sema::CheckCompleteVariableDeclaration Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007210155:202007220207 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=547690490144 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 51100] New: ESI not preserved on clobber if used as base register
https://bugs.llvm.org/show_bug.cgi?id=51100
Bug ID: 51100
Summary: ESI not preserved on clobber if used as base register
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: klrehm...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
If esi is used as a base pointer (i.e. in the case of dynamically sized allocas
on Windows x86), it won't properly be preserved even if marked as clobbered in
inline assembly.
A practical example of this being an issue is with `rep movsb` (and by
extension the __movsb intrinsic):
int test() {
// fake dynamic alloca
volatile auto size = 4;
auto x = (int*)__builtin_alloca(size);
*x = 1;
int g;
void *ptr = &g;
int c = 4;
// replicate __movsb intrinsic
asm("rep movsb" : "+D"(ptr), "+S"(x), "+c"(c)::"memory");
// miscompile here as esi is modified
return g;
}
https://godbolt.org/z/v3zqh8E96
This caused problems when LTO was used across different libraries that caused
two unrelated functions to be inlined.
`-mllvm -x86-use-base-pointer=false` fixes this by not using esi at all.
--
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 51101] New: .editorconfig
https://bugs.llvm.org/show_bug.cgi?id=51101 Bug ID: 51101 Summary: .editorconfig Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: nn1436...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org .editorconfig ( https://editorconfig.org/ ) is the standard way to define code formatting and analysis rules. The main advantage of editorconfig file is filtering options which are unavailable in Clang Format YAML. The conversion from YAML to editorconfig can be done straight-forward, for example: .clang-format Language: Cpp AccessModifierOffset: -4 AlignAfterOpenBracket: Align .editorconfig [*.cpp] clang_format_cpp_access_modifier_offset = -4 clang_format_cpp_align_after_open_bracket = align # Can specify different rule for a different filter [tests/*.cpp] clang_format_cpp_access_modifier_offset = 8 -- 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 51102] New: [AArch64] Wrong code generated (?) for compare_exchange_strong on __int128_t
https://bugs.llvm.org/show_bug.cgi?id=51102
Bug ID: 51102
Summary: [AArch64] Wrong code generated (?) for
compare_exchange_strong on __int128_t
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: efrie...@quicinc.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
Consider:
#include
__int128_t ff(_Atomic __int128_t *p) {
__int128_t e = 0;
atomic_compare_exchange_strong(p, &e, 0);
return e;
}
ff:
mov x8, x0
.LBB0_1:
ldaxp x0, x1, [x8]
orr x9, x0, x1
cbnzx9, .LBB0_4
stlxp w9, xzr, xzr, [x8]
cbnzw9, .LBB0_1
ret
.LBB0_4:
clrex
ret
This sequence is subtly wrong in the case where the cmpxchg fails.
Specifically, the ldaxp is not single-copy atomic, so the returned value might
tear. At least, that's my understanding of the rules here. So we need to
replace the "clrex" with a sequence like "stlxp w9, x0, x1, [x8]; cbnz w9,
.LBB0_1".
Not sure if this sort of tearing can actually happen in practice on commonly
used AArch64 chips.
I'll throw together 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
