[llvm-bugs] [Bug 28661] New: [AVX512] incorrect code for boolean expression at -O0.
https://llvm.org/bugs/show_bug.cgi?id=28661
Bug ID: 28661
Summary: [AVX512] incorrect code for boolean expression at -O0.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: babo...@gmail.com
CC: elena.demikhov...@intel.com, igor.bre...@intel.com,
llvm-bugs@lists.llvm.org, vsevolod.livins...@frtk.ru
Classification: Unclassified
Created attachment 16791
--> https://llvm.org/bugs/attachment.cgi?id=16791&action=edit
reproducer
Simple test case triggers incorrect code generation on AVX512 at -O0.
#include
int main() {
bool b = true;
bool res = ((bool) (!(! b))) && true;
printf("%d (expected 1)\n", res);
return 0;
}
> clang++ -O0 knl_bool_bug.cpp -march=knl
> sde -knl -- ./a.out
0 (expected 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 28662] New: Type with no linkage in signature: symbols for unique entities link together
https://llvm.org/bugs/show_bug.cgi?id=28662
Bug ID: 28662
Summary: Type with no linkage in signature: symbols for unique
entities link together
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Keywords: miscompilation
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: hst...@ca.ibm.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang produces symbols for entities which cannot possibly be referenced from
another translation unit in such a way that distinct entities link together.
In the following program, the templates in question are neither equivalent nor
functionally equivalent.
Online compiler: http://melpon.org/wandbox/permlink/okS5TiGDAVgd8tb0
### SOURCE (a.cc):
extern "C" void abort();
void bar();
namespace {
template struct A { A(int); char sizer[1]; };
}
template void foo(char (*)[sizeof A(T(0))]) {
static unsigned cnt = 0;
if (cnt++) abort();
}
int main(void) { bar(); foo(0); }
### SOURCE (b.cc):
extern "C" void abort();
namespace {
template struct A { A(int); char sizer[2]; };
}
template void foo(char (*)[sizeof A(T(0))]) {
static unsigned cnt = 0;
if (cnt++) abort();
}
void bar() { foo(0); }
### COMMANDS:
clang++ -c -o a.o -std=c++11 a.cc
clang++ -c -o b.o -std=c++11 b.cc
clang++ -o a.out a.o b.o
./a.out
### EXPECTED OUTPUT:
rc=0
### ACTUAL OUTPUT:
(aborts)
### COMPILER VERSION INFO (clang++ -v):
clang version 4.0.0 (trunk 276290)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
--
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 28663] New: sspstrong and sspreq use generate incorrect frame layout with alloca and VLAs
https://llvm.org/bugs/show_bug.cgi?id=28663
Bug ID: 28663
Summary: sspstrong and sspreq use generate incorrect frame
layout with alloca and VLAs
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: danielmi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16793
--> https://llvm.org/bugs/attachment.cgi?id=16793&action=edit
[PATCH] stop short-circuiting the SSP code for sspstrong
The StackProtector::RequiresStackProtector method is supposed to add layout
information for alloca instructions that need to be protected by the canary.
This is supposed to protect normal local variables (including function
pointers, etc.) from linear overflows.
However, this method contains an early return for sspstrong and sspreq in the
code for handling calls to alloca and variable length arrays (not regular
arrays, with the IR Clang generates):
// SSP-Strong: Enable protectors for any call to alloca, regardless
// of size.
if (Strong)
return true;
The method has special handling for sspstrong/sspreq following this early
return, but it's not being used. It ends up returning early, resulting in the
function being protected with a canary but without marking the arrays it's
trying to protect (not only the alloca/VLA triggering the issue) so they get
treated as normal local variables.
I've attached a patch removing this early return.
Example of how the code output changes (at -O0):
#include
#include
int foo(char *bar) {
char *buf = alloca(20);
strcpy(buf, bar);
return strlen(buf);
}
--- old_x86.s2016-07-22 08:44:37.534862251 -0400
+++ new_x86.s2016-07-22 08:44:18.778486803 -0400
@@ -17,12 +17,12 @@
subq$48, %rsp
movq%fs:40, %rax
movq%rax, -8(%rbp)
-movq%rdi, -24(%rbp)
-leaq-44(%rbp), %rdi
-movq%rdi, -16(%rbp)
-movq-24(%rbp), %rsi
+movq%rdi, -48(%rbp)
+leaq-28(%rbp), %rdi
+movq%rdi, -40(%rbp)
+movq-48(%rbp), %rsi
callqstrcpy
-movq-16(%rbp), %rdi
+movq-40(%rbp), %rdi
callqstrlen
movq%fs:40, %rcx
cmpq-8(%rbp), %rcx
--
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 27946] The llvm-tools package is gone from apt repositories
https://llvm.org/bugs/show_bug.cgi?id=27946 Sylvestre Ledru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Sylvestre Ledru --- It is back in 3.8, 3.9 & 4.0, many thanks :) It should be already live (or soon) I didn't credited you as I don't know your real name :( (but I can update the changelog if you want) -- 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 27698] error: redefinition of 'basic_streambuf' template class basic_streambuf {
https://llvm.org/bugs/show_bug.cgi?id=27698 Cristina Cristescu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Cristina Cristescu --- We lost the issue while reducing. The reproducer was not good enough. -- 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 28606] MC/Sparc tests failing on self-hosted 32-bit Windows builds
https://llvm.org/bugs/show_bug.cgi?id=28606 Sebastian Pop changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sebastian Pop --- Fixed in https://reviews.llvm.org/rL276358 -- 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 28600] [meta] 3.9.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=28600 Bug 28600 depends on bug 28606, which changed state. Bug 28606 Summary: MC/Sparc tests failing on self-hosted 32-bit Windows builds https://llvm.org/bugs/show_bug.cgi?id=28606 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28664] New: Expression is always true (file LoopInterchange.cpp)
https://llvm.org/bugs/show_bug.cgi?id=28664 Bug ID: 28664 Summary: Expression is always true (file LoopInterchange.cpp) Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: appchec...@cnpo.ru CC: llvm-bugs@lists.llvm.org Classification: Unclassified Hello! There is expression in function containsNoDependence (file lib/Transforms/Scalar/LoopInterchange.cpp, line 214): if (DepMatrix[Row][i] != '=' || DepMatrix[Row][i] != 'S' || DepMatrix[Row][i] != 'I') but it is always true. See similar sample - https://ideone.com/OX3Oyp This possible defect found by AppChecker (https://cnpo.ru/en/solutions/appchecker.php) -- 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 28657] Cannot select: intrinsic %llvm.x86.avx.vbroadcastf128.pd.256
https://llvm.org/bugs/show_bug.cgi?id=28657 Simon Pilgrim changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Reverted by r276405 Reapplied with fix by r276416 (llvm) and r276417 (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 18674] Assertion failed: ParseAssignmentExpression went over the default arg tokens
https://llvm.org/bugs/show_bug.cgi?id=18674 Elias Pipping changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Elias Pipping --- I believe this has been fixed for a long time. I can't even reproduce it with clang 3.5.2 anymore. Someone might still want to turn it into a test case, though. -- 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 14538] Impossible TemplateArgument
https://llvm.org/bugs/show_bug.cgi?id=14538 Elias Pipping changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Elias Pipping --- I believe this has been fixed for a long time. Can't reproduce it with clang 3.5.2, 3.6.2, 3.7.1, or 3.8.1. Closing. *** This bug has been marked as a duplicate of bug 14458 *** -- 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 28665] New: [InstSimplify] missing analysis for bit manipulation intrinsics
https://llvm.org/bugs/show_bug.cgi?id=28665
Bug ID: 28665
Summary: [InstSimplify] missing analysis for bit manipulation
intrinsics
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define i1 @ctlz_cmp_false(i32 %a) {
%x = tail call i32 @llvm.ctlz.i32(i32 %a, i1 false) nounwind readnone
%cmp = icmp ugt i32 %x, 32
ret i1 %cmp
}
define i1 @cttz_cmp_false(i32 %a) {
%x = tail call i32 @llvm.cttz.i32(i32 %a, i1 false) nounwind readnone
%cmp = icmp ugt i32 %x, 32
ret i1 %cmp
}
define i1 @ctpop_cmp_false(i32 %a) {
%x = tail call i32 @llvm.ctpop.i32(i32 %a) nounwind readnone
%cmp = icmp ugt i32 %x, 32
ret i1 %cmp
}
declare i32 @llvm.cttz.i32(i32, i1) nounwind readnone
declare i32 @llvm.ctlz.i32(i32, i1) nounwind readnone
declare i32 @llvm.ctpop.i32(i32) nounwind readnone
-
$ ./opt -instsimplify bitz.ll -S
(doesn't change anything)
Note that this does work:
define i1 @ctlz_cmp_true(i32 %a) {
%x = tail call i32 @llvm.ctlz.i32(i32 %a, i1 false) nounwind readnone
%cmp = icmp uge i32 %x, 0
ret i1 %cmp
}
$ ./opt -instsimplify bitz.ll -S
...
define i1 @ctlz_cmp_true(i32 %a) {
ret i1 true
}
--
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 28666] New: clang chrashes with -Wthread-safety in clang::CFGImplicitDtor::getDestructorDecl
https://llvm.org/bugs/show_bug.cgi?id=28666
Bug ID: 28666
Summary: clang chrashes with -Wthread-safety in
clang::CFGImplicitDtor::getDestructorDecl
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: n...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following example causes clang to chrash:
struct Holder {
virtual ~Holder() throw() {}
int i = 0;
};
int main() {
const auto &value = Holder().i;
}
Due to incorrect handling of lifetime-extending constructs.
--
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 28667] New: Invalid subexpression in sizeof fails to remove candidate
https://llvm.org/bugs/show_bug.cgi?id=28667
Bug ID: 28667
Summary: Invalid subexpression in sizeof fails to remove
candidate
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid, compile-fail, miscompilation
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: hst...@ca.ibm.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
In the following case, Clang fails to detect an error in the subexpression of
the sizeof during substitution of the template arguments into the signature of
the function in question.
Online compiler: http://melpon.org/wandbox/permlink/by24bjnKIvVPecSH
### SOURCE ():
struct A { A(int); };
template void foo(void *, char (*)[sizeof(0, A(T()))]) { }
template void foo(int, ...);
int main(void) { foo(0, 0); }
### COMPILER INVOCATION:
clang++ -cc1 -fsyntax-only -x c++ -std=c++11 -
### EXPECTED OUTPUT:
(clean compile)
### ACTUAL OUTPUT:
:6:18: error: call to 'foo' is ambiguous
int main(void) { foo(0, 0); }
^~
:3:28: note: candidate function [with T = nullptr_t]
template void foo(void *, char (*)[sizeof(0, A(T()))]) { }
^
:4:28: note: candidate function [with T = nullptr_t]
template void foo(int, ...);
^
1 error generated.
### COMPILER VERSION INFO (clang++ -v):
clang version 4.0.0 (trunk 276290)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
--
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 28668] New: [InstCombine] missing folds for bit manipulation intrinsics
https://llvm.org/bugs/show_bug.cgi?id=28668
Bug ID: 28668
Summary: [InstCombine] missing folds for bit manipulation
intrinsics
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define i1 @ctlz_cmp(i32 %a) {
%x = tail call i32 @llvm.ctlz.i32(i32 %a, i1 false) #0
%cmp = icmp eq i32 %x, 0 ; no zeros? --> all ones
ret i1 %cmp
}
define i1 @cttz_cmp(i32 %a) {
%x = tail call i32 @llvm.cttz.i32(i32 %a, i1 false) #0
%cmp = icmp eq i32 %x, 0 ; no zeros? --> all ones
ret i1 %cmp
}
define i1 @ctpop_cmp(i32 %a) {
%x = tail call i32 @llvm.ctpop.i32(i32 %a) #0
%cmp = icmp eq i32 %x, 32 ; all ones? --> no zeros
ret i1 %cmp
}
-
$ ./opt -instcombine more_bitz.ll -S
(doesn't change anything)
Note that these all work:
define i1 @ctlz_cmp(i32 %a) {
%x = tail call i32 @llvm.ctlz.i32(i32 %a, i1 false) nounwind readnone
%cmp = icmp eq i32 %x, 32 ; all zeros? --> no ones
ret i1 %cmp
}
define i1 @cttz_cmp(i32 %a) {
%x = tail call i32 @llvm.cttz.i32(i32 %a, i1 false) nounwind readnone
%cmp = icmp eq i32 %x, 32 ; all zeros? --> no ones
ret i1 %cmp
}
define i1 @ctpop_cmp(i32 %a) {
%x = tail call i32 @llvm.ctpop.i32(i32 %a) nounwind readnone
%cmp = icmp eq i32 %x, 0 ; no ones? --> all zeros
ret i1 %cmp
}
$ ./opt -instcombine more_bitz.ll -S
...
define i1 @ctlz_cmp(i32 %a) {
%cmp = icmp eq i32 %a, 0
ret i1 %cmp
}
define i1 @cttz_cmp(i32 %a) {
%cmp = icmp eq i32 %a, 0
ret i1 %cmp
}
define i1 @ctpop_cmp(i32 %a) {
%cmp = icmp eq i32 %a, 0
ret i1 %cmp
}
--
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 27699] error: definition of explicitly defaulted copy constructor basic_streambuf::basic_streambuf(const basic_streambuf &) = default;
https://llvm.org/bugs/show_bug.cgi?id=27699 Cristina Cristescu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Cristina Cristescu --- Fixed for modules 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 28669] New: Unnecessary vector type produces wrong ll parser error
https://llvm.org/bugs/show_bug.cgi?id=28669
Bug ID: 28669
Summary: Unnecessary vector type produces wrong ll parser error
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Core LLVM classes
Assignee: unassignedb...@nondot.org
Reporter: matthew.arsena...@amd.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This testcase produces a misleading parse error
; RUN: llvm-as < %s
define void @add_v2i16(<2 x i16> addrspace(1)* %out, <2 x i16> %in) {
%arst = add <2 x i16> %in, <2 x i16>
store <2 x i16> %arst, <2 x i16> addrspace(1)* %out
ret void
}
expected-type-wrong-error.ll:3:31: error: expected type
%arst = add <2 x i16> %in, <2 x i16>
It is erroring on the 2nd operand <2 x i16> type, it really means the type is
unexpected.
The correctly parsing version is
%arst = add <2 x i16> %in,
--
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 28670] New: GVNHoist pass uses a large amount of memory and appears to hang due to large increase in buildtime
https://llvm.org/bugs/show_bug.cgi?id=28670 Bug ID: 28670 Summary: GVNHoist pass uses a large amount of memory and appears to hang due to large increase in buildtime Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: alina.sbir...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16795 --> https://llvm.org/bugs/attachment.cgi?id=16795&action=edit Sample testcase The recently added GVNHoist pass causes certain Halide tests to take forever making Halide unusable. More details on discussion: https://reviews.llvm.org/D22639 Adding a sample testcase generated by Halide. Test using "opt -gvn-hoist gvnhoist_small.bc". An even larger testcase can be found here: https://drive.google.com/open?id=0B01oOnN8VyO8MnpIdlpBcmRybmc -- 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 28671] New: Difficult to find TemplateSpecializationType on http://clang.llvm.org/doxygen
https://llvm.org/bugs/show_bug.cgi?id=28671 Bug ID: 28671 Summary: Difficult to find TemplateSpecializationType on http://clang.llvm.org/doxygen Product: Website Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Documentation Assignee: unassignedb...@nondot.org Reporter: rtr...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified It is difficult to find the class TemplateSpecializationType. Not listed on the Class Index http://clang.llvm.org/doxygen/classes.html Not listed as a derived class of Type http://clang.llvm.org/doxygen/classclang_1_1Type.html A little searching finds the documentation for it, so it is generated, but not included in the usual locations. http://clang.llvm.org/doxygen/classclang_1_1TemplateSpecializationType.html -- 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 28672] New: Integer divide by constant close to UINT*_MAX can be compare rather than divide
https://llvm.org/bugs/show_bug.cgi?id=28672
Bug ID: 28672
Summary: Integer divide by constant close to UINT*_MAX can be
compare rather than divide
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: simon.ho...@arm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When doing unsigned division by an integer which is greater than `UINT_MAX / 2`
(or another range limit in place of UINT_MAX, as appropriate), the result can
be only 0 or 1, and this can be evaluated with a compare rather than a
reciprocal-multiply (or divide).
For example:
uint32_t f(uint32_t x) { return (x + 1) % 4000569407; }
is equivalent to:
uint32_t f(uint32_t x) { x++; return x < 4000569407 ? x : x - 4000569407; }
Clang gives me:
clang --target=arm-linux-gnueabihf -O3 -S -o- p1modk.c
ldr r1, .LCPI0_0// 316062335
add r0, r0, #1
umull r1, r2, r0, r1
sub r1, r0, r2
add r1, r2, r1, lsr #1
ldr r2, .LCPI0_1// 4000569407
lsr r1, r1, #31
mul r1, r1, r2
sub r0, r0, r1
I expect something more like:
ldr r1, =4000569407
add r0, r0, #1
cmp r0, r1
subhs r0, r0, r1
Note that this applicable in loops containing the `x = (x + 1) % k;` idiom if x
can be shown to be never greater than k (even if k is variable, I think).
--
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 28588] Use after free in DSE
https://llvm.org/bugs/show_bug.cgi?id=28588 Jun Bum Lim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jun Bum Lim --- Recommitted the change with fix in r276452 -- 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 28332] virtual void clang::ASTWriter::ResolvedExceptionSpec(const clang::FunctionDecl*): Assertion `!DoneWritingDeclsAndTypes && "Already done writing updates!"' failed.
https://llvm.org/bugs/show_bug.cgi?id=28332 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Vassil Vassilev --- Fixed in r276473. -- 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 28673] New: [ThinLTO] Assertion `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"' failed
https://llvm.org/bugs/show_bug.cgi?id=28673
Bug ID: 28673
Summary: [ThinLTO] Assertion `!(Pair.first != Ty && Pair.second
== Ty) && "mapping to a source type"' failed
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: t...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
ld: /home/twoh/llvms/latest-dev/llvm/lib/Linker/IRMover.cpp:319: llvm::Type*
{anonymous}::TypeMapTy::get(llvm::Type*, llvm::SmallPtrSet&): Assertion `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a
source type"' failed.
clang-3.9: error: unable to execute command: Aborted (core dumped)
clang-3.9: error: linker command failed due to signal (use -v to see
invocation)
Encountered the assertion failure while running ThinLTO.
--
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 28674] New: Failure to re-use immediate shared between compare and subtract
https://llvm.org/bugs/show_bug.cgi?id=28674
Bug ID: 28674
Summary: Failure to re-use immediate shared between compare and
subtract
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: simon.ho...@arm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given:
uint32_t f(uint32_t x) { x++; return x < 4000569407 ? x : x - 4000569407; }
Compiling with:
clang --target=arm-linux-gnueabihf -O3 -S -o- p1modk.c
I get:
ldr r2, .LCPI2_0 // =294397890
ldr r3, .LCPI2_1 // =4000569407
add r1, r0, #1
cmp r1, r3
addhs r1, r0, r2
mov r0, r1
I expect:
ldr r1, .LCPI2_1 // =4000569407
add r0, r0, #1
cmp r0, r1
subhs r0, r0, r1
Or possibly (unless I made a mistake):
ldr r1, .LCPI2_1 // =(4000569407 - 1)
subsr1, r0, r1
addlo r1, r0, #1
mov r0, r1
Seems to affect at least x86, ARM, and AArch64.
--
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 28528] Cannot select: intrinsic %llvm.aarch64.neon.sqshrun
https://llvm.org/bugs/show_bug.cgi?id=28528 Alina Sbirlea changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Alina Sbirlea --- The testcase is incorrect. The shift should be done "in the range 1 to the destination element width", i.e. 1-16, the test is using 18. -- 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 21179] No warnings for invalid memory orderings for atomic accesses
https://llvm.org/bugs/show_bug.cgi?id=21179 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Fiselier --- Fixed in r276506. Unfortunately instead of warnings the diagnostics generate errors, but I think that is better than nothing. -- 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 21179] No warnings for invalid memory orderings for atomic accesses
https://llvm.org/bugs/show_bug.cgi?id=21179 Eric Fiselier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Eric Fiselier --- Reopening for now. I had to revert the commit in r276507 because it didn't work well on Clang 3.6. I'll redo the patch with __unavailable_if if/when it gets implemented. -- 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 28062] clang crashes on valid code at -Os and above on x86_64-linux-gnu with Assertion `Elt < getNumElements() && "Invalid Elt"' failed
https://llvm.org/bugs/show_bug.cgi?id=28062 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|LLVM Codegen|Loop Optimizer Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | Product|clang |libraries --- Comment #2 from David Majnemer --- Fixed in r276510. -- 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 28676] New: -Wshadow doesn't warn on shadowed 'using' statements. Gcc does.
https://llvm.org/bugs/show_bug.cgi?id=28676
Bug ID: 28676
Summary: -Wshadow doesn't warn on shadowed 'using' statements.
Gcc does.
Product: clang
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: xax...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
using Foo=int;
int i;
int main(){
using Foo=char; // <== clang doesn't warn about this, gcc does
int i;
}
gcc catches both: https://godbolt.org/g/6heXBO
clang 3.8 doesn't warn on the shadowed 'using': https://godbolt.org/g/zTgIDn
Tested with every version of clang on godbolt down to 3.3 (lower was broken)
and got the same behavior on each version of clang.
gcc seems to catch both on every version that supports c++11.
--
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
