[llvm-bugs] [Bug 31486] New: Faulty expansion of UMAX/SMAX/UMIN/SMIN in ExpandIntRes_MINMAX
https://llvm.org/bugs/show_bug.cgi?id=31486
Bug ID: 31486
Summary: Faulty expansion of UMAX/SMAX/UMIN/SMIN in
ExpandIntRes_MINMAX
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17785
--> https://llvm.org/bugs/attachment.cgi?id=17785&action=edit
r600 mir reproducer
Originally found for an out-of-tree target.
Debug printouts show
SelectionDAG has 14 nodes:
t0: ch = EntryToken
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0
t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1
t7: i32 = AssertSext t5, ValueType:ch:i8
t8: i64 = build_pair t7, Constant:i32<0>
t12: i64 = umax t8, Constant:i64<4>
t15: ch = store t0, t12, undef:i16, undef:i16
t16: ch = PHXISD::RETURN t15
and then
Expand integer result: t12: i64 = umax t8, Constant:i64<4>
and
Legally typed node: t18: i32,i32 = umax Constant:i32<0>, Constant:i32<0>
Legally typed node: t23: i32,i32 = umax t7, Constant:i32<4>
so the i64 umax has ben expanded into two i32, i32 umax:es.
I would instead have expected two i32 umax.
So we get
Type-legalized selection DAG: BB#3 'func_37:bb11'
SelectionDAG has 16 nodes:
t0: ch = EntryToken
t18: i32,i32 = umax Constant:i32<0>, Constant:i32<0>
t24: ch = store t0, t18, undef:i16, undef:i16
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0
t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1
t7: i32 = AssertSext t5, ValueType:ch:i8
t23: i32,i32 = umax t7, Constant:i32<4>
t26: ch = store t0, t23, undef:i16, undef:i16
t27: ch = TokenFactor t24, t26
t16: ch = PHXISD::RETURN t27
and shortly after this we get a failing assertion
llc: ../lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1363: void (anonymous
namespace)::DAGCombiner::Run(llvm::CombineLevel): Assertion `N->getValueType(0)
== RV.getValueType() && N->getNumValues() == 1 && "Type mismatch"' failed.
#0 0x01b1c398 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/data/repo/llvm-dev2/build-all/./bin/llc+0x1b1c398)
#1 0x01b1cf36 SignalHandler(int)
(/data/repo/llvm-dev2/build-all/./bin/llc+0x1b1cf36)
#2 0x7f5e4c855330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x7f5e4b448c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x7f5e4b44c028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#5 0x7f5e4b441bf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#6 0x7f5e4b441ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x01889210 llvm::SelectionDAG::Combine(llvm::CombineLevel,
llvm::AAResults&, llvm::CodeGenOpt::Level)
(/data/repo/llvm-dev2/build-all/./bin/llc+0x1889210)
#8 0x019e07d4 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/data/repo/llvm-dev2/build-all/./bin/llc+0x19e07d4)
#9 0x019dec58
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/data/repo/llvm-dev2/build-all/./bin/llc+0x19dec58)
#10 0x019db4db
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/data/repo/llvm-dev2/build-all/./bin/llc+0x19db4db)
and here we have
(gdb) call N->dump()
t18: i32,i32 = umax Constant:i32<0>, Constant:i32<0>
(gdb) call RV.dump()
t3: i32 = Constant<0>
(gdb)
Changing
// Hi part is always the same op
Hi = DAG.getNode(N->getOpcode(), DL, {NVT, NVT}, {LHSH, RHSH});
into
// Hi part is always the same op
Hi = DAG.getNode(N->getOpcode(), DL, NVT, {LHSH, RHSH});
and
// Recursed Lo part if Hi parts are equal, this uses unsigned version
SDValue LoMinMax = DAG.getNode(LoOpc, DL, {NVT, NVT}, {LHSL, RHSL});
into
// Recursed Lo part if Hi parts are equal, this uses unsigned version
SDValue LoMinMax = DAG.getNode(LoOpc, DL, NVT, {LHSL, RHSL});
makes the crash go away, and no test cases under test fail.
Can also be reproduced on r600/cypress with
llc -march=r600 -mcpu=cypress -start-after safe-stack foo.mir
--
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 31487] New: new warning: warn when returning void expression
https://llvm.org/bugs/show_bug.cgi?id=31487
Bug ID: 31487
Summary: new warning: warn when returning void expression
Product: clang
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: l...@bobbyperu.info
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
This warning would catch bugs such as:
void doSomething()
void func()
{
if (condition)
return // Oops, forgot ; so doSomething() will be called
doSomething();
}
--
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 31478] No optimization of 'round' when arguments are known constants.
https://llvm.org/bugs/show_bug.cgi?id=31478 Bruno Jimenez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bruno Jimenez --- I have just tested with r290663 and it seems fixed (at least round doesn't show up anymore in the assembly) 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 31488] New: Win64 jump tables should not be executable and should not break SEH unwind info
https://llvm.org/bugs/show_bug.cgi?id=31488
Bug ID: 31488
Summary: Win64 jump tables should not be executable and should
not break SEH unwind info
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
r290569 switched Win64 from the PIC to static relocation model. This uncovered
some questionable jump table codegen for COFF objects.
The following LLVM IR switch generates a jump table:
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc19.0.24215"
define void @f(i32 %x) {
entry:
switch i32 %x, label %sw.epilog [
i32 0, label %sw.bb
i32 1, label %sw.bb1
i32 2, label %sw.bb2
i32 3, label %sw.bb3
]
sw.bb:; preds = %entry
tail call void @g(i32 0) #2
br label %sw.epilog
sw.bb1: ; preds = %entry
tail call void @g(i32 1) #2
br label %sw.epilog
sw.bb2: ; preds = %entry
tail call void @g(i32 2) #2
br label %sw.epilog
sw.bb3: ; preds = %entry
tail call void @g(i32 3) #2
br label %sw.epilog
sw.epilog:; preds = %entry, %sw.bb3,
%sw.bb2, %sw.bb1, %sw.bb
tail call void @g(i32 10) #2
ret void
}
declare void @g(i32)
Compiling twice with llc -relocation-model pic and -relocation-model static
produces these differing assemblies:
$ diff -u static.s pic.s
--- static.s2016-12-28 09:44:15.132872900 -0800
+++ pic.s 2016-12-28 09:44:19.827504200 -0800
@@ -18,7 +18,10 @@
ja .LBB0_7
# BB#1: # %entry
movl%ecx, %eax
- jmpq*.LJTI0_0(,%rax,8)
+ leaq.LJTI0_0(%rip), %rcx
+ movslq (%rcx,%rax,4), %rax
+ addq%rcx, %rax
+ jmpq*%rax
.LBB0_2:# %sw.bb
xorl%ecx, %ecx
jmp .LBB0_6
@@ -36,15 +39,14 @@
movl$10, %ecx
addq$40, %rsp
jmp g # TAILCALL
- .section.rdata,"dr"
- .p2align3
+ .p2align2, 0x90
.LJTI0_0:
- .quad .LBB0_2
- .quad .LBB0_3
- .quad .LBB0_4
- .quad .LBB0_5
+ .long .LBB0_2-.LJTI0_0
+ .long .LBB0_3-.LJTI0_0
+ .long .LBB0_4-.LJTI0_0
+ .long .LBB0_5-.LJTI0_0
.seh_handlerdata
- .section.rdata,"dr"
+ .text
.Lcfi3:
.seh_endproc
Problem one is that .seh_endproc needs to occur in the same section as
.seh_proc, and the .rdata switch breaks that.
Problem two is that in today's PIC model, this jump table is unnecessarily in
the .text section. MSVC also does this, FWIW, but we can definitely put this
jump table in a separate COMDAT-associative .rdata section.
We definitely *don't* want the .quad codegen, since that will produce runtime
relocations and waste space. This leaves two choices: image relative
relocations, or '.LBBN_M - .Lfunc_beginN', which can be fixed up by the
assembler. MSVC uses image relative relocations, which I suppose are nice if
you have some kind of post-link tool, but the fixups seem nicer from an object
size perspective.
--
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 31489] New: SEGV when swapping two std:function's at the same location
https://llvm.org/bugs/show_bug.cgi?id=31489
Bug ID: 31489
Summary: SEGV when swapping two std:function's at the same
location
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zonrx...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
This can be reproduced easily with the following program and commannds:
$ cat a.cpp
#include
#include
#include
#include
int main() {
std::function a = []() {};
std::swap(a, a);
return 0;
}
$ clang++ -ggdb -std=c++11 -o a a.cpp
$ ./a
Segmentation fault: 11
$ lldb ./a
(lldb) target create "./a"
Current executable set to './a' (x86_64).
(lldb) r
...
1780__f_->__clone(__t);
1781__f_->destroy();
1782__f_ = 0;
-> 1783__f.__f_->__clone((__base*)&__buf_);
1784__f.__f_->destroy();
1785__f.__f_ = 0;
1786__f_ = (__base*)&__buf_;
Both Mac (Apple LLVM version 8.0.0) and Linux (LLVM/Clang 3.8.0 release) have
the same problem at the same line.
--
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 31491] New: NewGVN cause clang to crash when compiling neon
https://llvm.org/bugs/show_bug.cgi?id=31491 Bug ID: 31491 Summary: NewGVN cause clang to crash when compiling neon Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lukebe...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17787 --> https://llvm.org/bugs/attachment.cgi?id=17787&action=edit Reproducer .c Steps to reproduce: 1. Download neon 0.30.0, http://www.webdav.org/neon/ 2. export CFLAGS="-O3 -march=native -mllvm -enable-newgvn" 3. ./autogen.sh &&& ./configure && make Output: /include/mit-krb5 -I.. -DNE_PRIVATE=extern -O3 -march=native -mllvm -enable-newgvn -prefer-pic -c ne_auth.c -o ne_auth.lo clang-4.0: error: unable to execute command: Killed clang-4.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.0 (trunk 290647) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-4.0: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-4.0: note: diagnostic msg: /tmp/ne_auth-4a6c83.c clang-4.0: note: diagnostic msg: /tmp/ne_auth-4a6c83.sh -- 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 31482] Attributes in a type-specifier-seq
https://llvm.org/bugs/show_bug.cgi?id=31482 Aaron Ballman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Aaron Ballman --- (In reply to comment #1) > Here's the grammar: > > type-specifier-seq: > type-specifier attribute-specifier-seq[opt] > type-specifier type-specifier-seq > > Note that this only permits attributes at the end of the sequence, not in > the middle. Ah, that's a good point. I didn't notice that. > The other compilers are wrong to accept your example. Perhaps we > could use the 'misplaced attributes' diagnostic instead, and explicitly say > where the attributes should be written? That might not be a bad idea, but I no longer consider this to be a bug with Clang. -- 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 31482] Attributes in a type-specifier-seq
https://llvm.org/bugs/show_bug.cgi?id=31482 Aaron Ballman changed: What|Removed |Added Resolution|FIXED |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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31492] New: [PPC] slower vsx instructions generated for vmac
https://llvm.org/bugs/show_bug.cgi?id=31492 Bug ID: 31492 Summary: [PPC] slower vsx instructions generated for vmac Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: car...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17789 --> https://llvm.org/bugs/attachment.cgi?id=17789&action=edit testcase The attached test case is simplified from vmac. Compile it with options -m64 -O2 -mvsx -mcpu=power8 LLVM generates following code for the while loop .LBB0_2:# %while.body # =>This Inner Loop Header: Depth=1 lxvd2x 0, 0, 7 // * lxvd2x 1, 0, 6 // * xxswapd 34, 0 // * xxswapd 35, 1 // * vaddudm 2, 3, 2// * xxswapd 10, 34// * mfvsrd 9, 34 // * mfvsrd 10, 10 // * #APP mulhdu 11, 10, 9 #NO_APP lxvd2x 11, 7, 8 lxvd2x 12, 0, 5 mulld 9, 9, 10 addi 7, 7, 64 xxswapd 50, 11 xxswapd 51, 12 vaddudm 2, 19, 18 xxswapd 13, 34 mfvsrd 0, 34 mfvsrd 12, 13 mulld 10, 0, 12 #APP mulhdu 12, 12, 0 #NO_APP #APP addc 3, 9, 10 adde 4, 11, 12 #NO_APP bdnz .LBB0_2 There are two problems: 1. (kp)[i] is loop invariant, its loading can be hoisted before the loop. 2. llvm generates vsx code marked * for the expression get64PE((mp) + i) + (kp)[i] if we use simple integer load and add instructions, it will be shorter and faster. For large input, it can be 35% faster. Looks like cost model problem in vectorization? -- 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 31304] Wrongly detected Called C++ object pointer is null for QModelIndex
https://llvm.org/bugs/show_bug.cgi?id=31304 Leslie Zhai changed: What|Removed |Added 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
