[llvm-bugs] [Bug 24549] New: ARM backend crash when compiling half-precision FP op without hardware FP
https://llvm.org/bugs/show_bug.cgi?id=24549
Bug ID: 24549
Summary: ARM backend crash when compiling half-precision FP op
without hardware FP
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: oliver.stann...@arm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This IR causes the ARM backend to crash when it is compiled for a target that
does not have any floating-point hardware:
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "armv7--none-eabi"
define void @foo(half* %a, half* %b, half* %c) {
entry:
%d = load half, half* %a
%e = load half, half* %b
%f = fadd half %d, %e
store half %f, half* %c
ret void
}
This is the error I get (with a recent trunk build):
$ llc test.ll -mattr=-vfp2
LLVM ERROR: Unsupported library call operation!
LLVM is attempting to lower the half-precision fadd to a library call, but
there are no library calls for half-precision. it should probably promote the
value to float (as it does when f32 is legal but f16 is not), and then emit f32
library calls.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24550] New: Assertion `oldBlock->capturesCXXThis() == blockScope->isCXXThisCaptured()
https://llvm.org/bugs/show_bug.cgi?id=24550
Bug ID: 24550
Summary: Assertion `oldBlock->capturesCXXThis() ==
blockScope->isCXXThisCaptured()
Product: new-bugs
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: benja...@tudos.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 14765
--> https://llvm.org/bugs/attachment.cgi?id=14765&action=edit
run script
Compiling the code below with -fblocks causes clang to trigger it's own
assertion. The run script is attached as requested, the preprocessed source
code looks identical to the code below.
[ --- code --- ]
typedef void (^Block)();
void invoke_block (Block block);
// --- a class
class A
{
public:
int f () { return 0; }
};
// --- template base class ---
template
class Base
{
public:
T * t;
virtual void virtual_function () {}
};
// --- derive from template base class
template
class Derv : public Base
{
virtual void virtual_function ();
};
template
void Derv::virtual_function ()
{
invoke_block (^() {
int i = Base::t->f ();
});
}
int main(int argc, char **argv)
{
Derv d;
return 0;
}
[ --- end of code --- ]
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24551] New: instruction step over thread exit fails on linux
https://llvm.org/bugs/show_bug.cgi?id=24551 Bug ID: 24551 Summary: instruction step over thread exit fails on linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified NativeProcessLinux fails to stop the process after the thread has exited, and the process continues to run freely until interrupted. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24552] New: LLVM ERROR: Cannot select: 0x100297f3db8: i32 = select_cc 0x100297f1fb8, 0x100297f5248, 0x100297f3918, 0x100297f3a40, 0x100297f36c8 [ORD=2] [ID=29]
https://llvm.org/bugs/show_bug.cgi?id=24552 Bug ID: 24552 Summary: LLVM ERROR: Cannot select: 0x100297f3db8: i32 = select_cc 0x100297f1fb8, 0x100297f5248, 0x100297f3918, 0x100297f3a40, 0x100297f36c8 [ORD=2] [ID=29] Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: an...@samba.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14766 --> https://llvm.org/bugs/attachment.cgi?id=14766&action=edit Failing testcase csmith hit the following fail: llc bugpoint-reduced-simplified.ll LLVM ERROR: Cannot select: 0x100297f3db8: i32 = select_cc 0x100297f1fb8, 0x100297f5248, 0x100297f3918, 0x100297f3a40, 0x100297f36c8 [ORD=2] [ID=29] 0x100297f1fb8: i1 = setcc 0x100297f35a0, 0x100297f5370, 0x100297f1e90 [ORD=2] [ID=26] 0x100297f35a0: i64 = add 0x100297f5498, 0x100297f3478 [ORD=2] [ID=24] 0x100297f5498: i64,ch = PPCISD::TOC_ENTRY 0x100297f1d68, 0x100297f18c8 [ORD=2] [ID=22] 0x100297f1d68: i64 = TargetGlobalAddress<[10 x [4 x i64]]* @g_386> 0 [ORD=2] [ID=16] 0x100297f18c8: i64 = Register %X2 [ID=12] 0x100297f3478: i64 = Constant<304> [ID=10] 0x100297f5370: i64,ch = PPCISD::TOC_ENTRY 0x100297f20e0, 0x100297f18c8 [ORD=2] [ID=21] 0x100297f20e0: i64 = TargetGlobalAddress 0 [ORD=2] [ID=15] 0x100297f18c8: i64 = Register %X2 [ID=12] 0x100297f5248: i1 = setcc 0x100297f3228, 0x100297f37f0, 0x100297f3b68 [ORD=2] [ID=28] 0x100297f3228: i64 = zero_extend 0x100297f3100 [ORD=2] [ID=27] 0x100297f3100: i1 = setcc 0x100297f2330, 0x100297f1b18, 0x100297f2580 [ORD=2] [ID=25] 0x100297f2330: i64 = add 0x100297f1c40, 0x100297f2208 [ORD=2] [ID=23] 0x100297f1c40: i64,ch = PPCISD::TOC_ENTRY 0x100297f2458, 0x100297f18c8 [ORD=2] [ID=20] 0x100297f2458: i64 = TargetGlobalAddress<[7 x i32]* @g_312> 0 [ORD=2] [ID=14] 0x100297f18c8: i64 = Register %X2 [ID=12] 0x100297f2208: i64 = Constant<12> [ID=2] 0x100297f1b18: i64,ch = PPCISD::TOC_ENTRY 0x100297f3c90, 0x100297f18c8 [ORD=2] [ID=19] 0x100297f3c90: i64 = TargetGlobalAddress 0 [ORD=2] [ID=13] 0x100297f18c8: i64 = Register %X2 [ID=12] 0x100297f37f0: i64 = Constant<0> [ID=8] 0x100297f3918: i32 = Constant<-108> [ID=5] 0x100297f3a40: i32 = Constant<0> [ID=6] In function: main -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24553] New: pro hand does not handle all SIGSEGV/SIGBUS signals
https://llvm.org/bugs/show_bug.cgi?id=24553 Bug ID: 24553 Summary: pro hand does not handle all SIGSEGV/SIGBUS signals Product: lldb Version: 3.2 Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: artag...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified (lldb) pro hand -p true -n false -s false SIGSEGV SIGBUS (lldb) r >> Process 6682 stopped * thread #32: tid = 0xfda1, 0x0001117060ec, name = 'Java: connector web server', stop reason = signal SIGSEGV frame #0: 0x0001117060ec -> 0x1117060ec: movl 0x8(%rax), %r11d 0x1117060f0: cmpl $0xfb0015c7, %r11d 0x1117060f7: jne0x1117069a9 0x1117060fd: testl %ebp, %ebp I can't produce a reduced usecase, and the code in question is proprietary, so I'm not sure what to do. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24554] New: Windows sanitizer tests are flaky due to LNK1104, when the linker cannot overwrite the last executable
https://llvm.org/bugs/show_bug.cgi?id=24554 Bug ID: 24554 Summary: Windows sanitizer tests are flaky due to LNK1104, when the linker cannot overwrite the last executable Product: compiler-rt Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: aa...@aaronballman.com, llvm-bugs@lists.llvm.org, pe...@pcc.me.uk Classification: Unclassified The sanitizer tests (asan, ubsan, etc) often have RUN lines like the following: // RUN: %clangxx -fsanitize=integer-divide-by-zero -DDIVIDEND=0 %s -o %t && %run %t 2>&1 | FileCheck %s // RUN: %clangxx -fsanitize=integer-divide-by-zero -DDIVIDEND=1U %s -o %t && %run %t 2>&1 | FileCheck %s // RUN: %clangxx -fsanitize=float-divide-by-zero -DDIVIDEND=1.5 %s -o %t && %run %t 2>&1 | FileCheck %s This repeatedly compiles the test with different settings, links it, and runs it in place. This pattern fails every so often on Windows for reasons that aren't fully understood. It seems like the %t process is still alive when the next linker command is running, and Windows doesn't let you overwrite EXEs or DLLs that are in use. It's possible that this is a Python/lit bug. If the lit process isn't closing it's process handle before running the next command, that might be the cause. It's possible that this is caused by anti-virus software that is still scanning the executable, but unlikely, since the sanitizer-windows buildbot doesn't have any third-party AV on it. Regardless, we should fix it. One workaround is to not reuse %t over and over in tests, but this will be difficult to enforce, since it works on Linux. Another workaround is to make '%run' on Windows expand to a wrapper program that waits for the child process to really exit. If the theory about 'lit' is correct, the best fix would be to use the Popen object to explicitly close the handle before running the next 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24555] New: Small typo in release notes
https://llvm.org/bugs/show_bug.cgi?id=24555 Bug ID: 24555 Summary: Small typo in release notes Product: Documentation Version: 3.7 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: schnet...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The 3.7 release notes contain the line "Wpessimizing-move warns when a local variable is ir moved on return and the". In this line, the word "ir" should be removed. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24556] New: naked functions with parameters are impossible to use correctly
https://llvm.org/bugs/show_bug.cgi?id=24556
Bug ID: 24556
Summary: naked functions with parameters are impossible to use
correctly
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: froy...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following testcase is a cut-down version of real code from Firefox:
struct siginfo_t;
// Shortened to act as an example.
struct sigaction {
void (*sa_sigaction)(int, siginfo_t*, void*);
};
extern void SetSignalHandler(int sig, struct sigaction*);
// Some (old) Linux kernels on ARM have a bug where a signal handler
// can be called without clearing the IT bits in CPSR first. The result
// is that the first few instructions of the handler could be skipped,
// ultimately resulting in crashes. To workaround this bug, the handler
// on ARM is a trampoline that starts with enough NOP instructions, so
// that even if the IT bits are not cleared, only the NOP instructions
// will be skipped over.
template
__attribute__((naked)) void
SignalTrampoline(int aSignal, siginfo_t* aInfo, void* aContext)
{
asm volatile (
"nop; nop; nop; nop"
: : : "memory");
// Because the assembler may generate additional insturctions below, we
// need to ensure NOPs are inserted first by separating them out above.
asm volatile (
"bx %0"
:
: "r"(H)
#ifndef __clang__
, "l"(aSignal), "l"(aInfo), "l"(aContext)
#endif
: "memory");
}
extern void MySignalHandler(int, siginfo_t*, void*);
void
f()
{
struct sigaction sa;
sa.sa_sigaction = SignalTrampoline;
SetSignalHandler(0, &sa);
}
The #ifndef __clang__ is needed because clang doesn't permit references to
local variables in naked functions. But then there's no way to communicate the
dependence that the asm statement has on the function's parameters. The
generated assembly (-O2 -fno-exceptions -fno-rtti) looks like:
.fnstart
@ BB#0:
ldrr0, .LCPI1_0
ldrr1, .LCPI1_1
@APP
movr0, r0
movr0, r0
movr0, r0
movr0, r0
@NO_APP
.LPC1_0:
addr0, pc, r0
ldrr0, [r1, r0]
@APP
bxr0
@NO_APP
.align2
@ BB#1:
.LCPI1_0:
.long_GLOBAL_OFFSET_TABLE_-(.LPC1_0+8)
.LCPI1_1:
.long_Z15MySignalHandleriP9siginfo_tPv(GOT)
.Lfunc_end1:
Both small sequences of code prior to the @APP directives clobber the argument
registers, which is undesirable. (This sample also exhibits undesirable
behavior in that part of the load of the function address to jump to is moved
above the first asm statement. But one thing at a time.)
GCC, AFAICT, gets this correct. (I haven't checked GCC trunk, but the Android
NDK compilers and the arm-none-eabi cross compiler on my Linux distribution
generate code that does the right thing 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24555] Small typo in release notes
https://llvm.org/bugs/show_bug.cgi?id=24555 rtr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||rtr...@google.com Resolution|--- |FIXED --- Comment #1 from rtr...@google.com --- Fixed in r245857. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24557] New: A few edge cases related to quote handling are broken on Windows
https://llvm.org/bugs/show_bug.cgi?id=24557 Bug ID: 24557 Summary: A few edge cases related to quote handling are broken on Windows Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified TestQuoting.test_bare_double TestQuoting.test_bare_single TestQuoting.test_no_quote TestQuoting.test_single_in_double TestQuoting.test_double_in_single TestQuoting.test_double_quote_escape TestQuoting.test_double_quote_escape2 TestQuoting.test_single_quote_escape TestQuoting.test_single_quote either fail or crash on Windows for various reasons. Once fixed, unit tests should be added against the Args class for this as well. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24546] PowerPC backend hits "Inconsistency: def of vector reg not found in swap map!" assertion in PPCVSXSwapRemoval.cpp:613
https://llvm.org/bugs/show_bug.cgi?id=24546 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Bill Schmidt --- Fixed as r245862. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24558] New: Inferior not getting reaped in certain situations
https://llvm.org/bugs/show_bug.cgi?id=24558 Bug ID: 24558 Summary: Inferior not getting reaped in certain situations Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Various tests on Windows fail because during cleanup, python tries to delete the executable and this fails because LLDB is still holding onto a handle to the process. This affects, at a minimum, the following tests, which are all XFAILED as a result of this. TestLLDBIterator.LLDBIteratorTestCase.test_lldb_iter_module TestTargetAPI.TargetAPITestCase.test_get_code_byte_size_with_dwarf TestTargetAPI.TargetAPITestCase.test_get_data_byte_size_with_dwarf TestTargetAPI.TargetAPITestCase.test_find_functions_with_dwarf TestThreadStepOut.ThreadStepOutTestCase.test_step_all_threads_with_dwarf TestThreadStepOut.ThreadStepOutTestCase.test_step_single_thread_with_dwarf -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24559] New: GNU attributes after declspecs don't parse
https://llvm.org/bugs/show_bug.cgi?id=24559
Bug ID: 24559
Summary: GNU attributes after declspecs don't parse
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: aa...@aaronballman.com, david.majne...@gmail.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
With clang-cl, this parses fine:
struct __attribute__((lockable)) __declspec(dllexport) S { };
while this does not:
struct __declspec(dllexport) __attribute__((lockable)) T { };
/tmp/a.cc(3,1) : error: declaration of anonymous struct must be a definition
struct __declspec(dllexport) __attribute__((lockable)) T { };
^
/tmp/a.cc(3,1) : warning: declaration does not declare anything
[-Wmissing-declarations]
struct __declspec(dllexport) __attribute__((lockable)) T { };
^
It would be great if we could allow both orderings, or at least provide a
better error message.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24560] New: arm assembler does not share constant pool
https://llvm.org/bugs/show_bug.cgi?id=24560
Bug ID: 24560
Summary: arm assembler does not share constant pool
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: Cell SPU
Assignee: unassignedb...@nondot.org
Reporter: c...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Arm target assembler should share constants in the constant pool.
Input: x.s
.arm
.text
.global foo1
foo1:
PUSH {r4-r6,lr}
LDR r7, =0x80808080
LDR r7, =0x80808080
POP {r4-r6,pc}
.global foo2
foo2:
PUSH {r4-r6,lr}
LDR r7, =0x80808080
POP {r4-r6,pc}
.global foo3
.end
Compile with:
clang -target arm-linux-gnu -c -o x.o x.s
Objdump showed 3 instances of the constant 0x80808080:
:
0: e92d4070push{r4, r5, r6, lr}
4: e59f7010ldr r7, [pc, #16] ; 1c
8: e59f7010ldr r7, [pc, #16] ; 20
c: e8bd8070pop {r4, r5, r6, pc}
0010 :
10: e92d4070push{r4, r5, r6, lr}
14: e59f7008ldr r7, [pc, #8]; 24
18: e8bd8070pop {r4, r5, r6, pc}
1c: 80808080addhi r8, r0, r0, lsl #1
20: 80808080addhi r8, r0, r0, lsl #1
24: 80808080addhi r8, r0, r0, lsl #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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24561] New: [msan] False positive on icmp sgt (trunc %x), -1
https://llvm.org/bugs/show_bug.cgi?id=24561
Bug ID: 24561
Summary: [msan] False positive on icmp sgt (trunc %x), -1
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat 1.cc
#include
struct A {
bool c1 : 7;
bool c8 : 1;
bool c9 : 1;
A();
};
__attribute__((noinline)) A::A() : c8(false) {}
int main() {
A* a = new A();
if (a->c8)
printf("zz\n");
return 0;
}
$ clang++ 1.cc -O2 -fsanitize=memory && ./a.out
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f8dd5a8712c in main 1.cc:15:7
...
Bitcode for the "if" instruction:
%10 = bitcast i8* %call to i16*
%bf.load = load i16, i16* %10, align 1
%11 = trunc i16 %bf.load to i8
%bf.cast = icmp sgt i8 %11, -1
br i1 %bf.cast, label %if.end, label %if.then
MSan instrumentation:
%bf.load = load i16, i16* %1, align 1
%4 = ptrtoint i16* %1 to i64
%5 = and i64 %4, -70368744177665
%6 = inttoptr i64 %5 to i16*
%_msld = load i16, i16* %6, align 1
%_msprop = trunc i16 %_msld to i8
%7 = trunc i16 %bf.load to i8
>>> BUG
%8 = trunc i8 %_msprop to i1
%bf.cast = icmp sgt i8 %7, -1
<<<
%_mscmp2 = icmp ne i1 %8, false
br i1 %_mscmp2, label %9, label %10, !prof !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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24562] New: pshufb intrinsic doesn't understand that indices with high-bit set give zeros
https://llvm.org/bugs/show_bug.cgi?id=24562 Bug ID: 24562 Summary: pshufb intrinsic doesn't understand that indices with high-bit set give zeros Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: dbau...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14767 --> https://llvm.org/bugs/attachment.cgi?id=14767&action=edit C file to compare clang/LLVM and GCC The `pshufb` SSSE3 instruction takes two vectors of i8's, x and y, and returns , except for indices where the high bit is set, which return zero. LLVM seems to ignore the high-bit, and will lower calls to `llvm.x86.ssse3.pshuf.b.128` as if they unconditionally indexed with the mask. The attached pshufb.c file prints "1 1 ... 1" with clang, and "0 0 ... 0" with gcc. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24563] New: LiveDebugVariables propagates constant values without joining at bb boundaries
https://llvm.org/bugs/show_bug.cgi?id=24563
Bug ID: 24563
Summary: LiveDebugVariables propagates constant values without
joining at bb boundaries
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Found while reviewing http://reviews.llvm.org/D11933
Compiling the following testcase at -O1
void g(int *);
int f() {
int x = 23;
g(&x);
if (x == 42)
++x;
return x;
}
will cause the constant value 23 to be propagated into the last basic block:
BB#2: derived from LLVM BB %if.end
Predecessors according to CFG: BB#0 BB#1
DBG_VALUE 23, 0, !"x", ; line no:3
%EAX = MOV32rm %RSP, 1, %noreg, 4, %noreg; mem:LD4[%x](tbaa=!17)
dbg:r.c:7:10
%RDX = POP64r %RSP, %RSP; dbg:r.c:7:3
RETQ %EAX; dbg:r.c:7:3
Looking into this I found that LiveDebugVariables is the culprit here:
void UserValue::extendDef(SlotIndex Idx, unsigned LocNo,
LiveRange *LR, const VNInfo *VNI,
SmallVectorImpl *Kills,
LiveIntervals &LIS, MachineDominatorTree &MDT,
UserValueScopes &UVS) {
...
for (unsigned i = 0, e = Children.size(); i != e; ++i) {
MachineBasicBlock *MBB = Children[i]->getBlock();
if (UVS.dominates(MBB))
Todo.push_back(LIS.getMBBStartIdx(MBB));
}
}
It look like it just unconditionally propagates all DBG_VALUEs down the
dominator tree, which happens to work fine if there already is another
DBG_VALUE but is wrong if the DBG_VALUE is coming from only one of the
predecessors like in this example here.
The DBG_VALUES should only end up in a subsequent basic block if they appear at
the end of all predecessors.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24544] PowerPC backend hits "Addend source register is not live!" assertion in PPCVSXFMAMutate.cpp:188
https://llvm.org/bugs/show_bug.cgi?id=24544 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hal Finkel --- Fixed by r245907, 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24542] [powerpc-ubuntu] code generation failure
https://llvm.org/bugs/show_bug.cgi?id=24542 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hal Finkel --- (In reply to comment #1) > The attached test case does crash; fixed in r245741. However, it crashes for > a reason related to undef handling, and I suspect it was over-reduced from > the original problem. If the original problem still exists, please try > running bugpoint again after r245741. I believe this likely to be the same bug reported in PR24544, fixed in r245907. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 20460] [C++11] allocate_shared should not require rebind of an allocator
https://llvm.org/bugs/show_bug.cgi?id=20460 Bug 20460 depends on bug 20616, which changed state. Bug 20616 Summary: shared_ptr does not compile with fancy pointer allocators https://llvm.org/bugs/show_bug.cgi?id=20616 What|Removed |Added Status|REOPENED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 20616] shared_ptr does not compile with fancy pointer allocators
https://llvm.org/bugs/show_bug.cgi?id=20616
Eric Fiselier changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #24 from Eric Fiselier ---
Hi Thomas, I'm closing this as resolved fixed again. I looked into the deque
failures and they were cased by OffPtr diss-allowing conversions that real
pointers accept. Please re-open if you disagree with this. Below is an example
conversion accepted by real pointers but not OffPtr.
int main() {
{
int* const* p = nullptr;
const int* const* p2 = p;
}
{
OffPtr > p = nullptr;
OffPtr > p2 = p; // Doesn't compile
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
