[llvm-bugs] [Bug 30925] TokenLexer.cpp:743: clang::SourceLocation clang::TokenLexer::getExpansionLocForMacroDefLoc(clang::SourceLocation) const: Assertion `ExpandLocStart.isValid() && MacroExpansionSt
https://llvm.org/bugs/show_bug.cgi?id=30925 octoploid changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from octoploid --- seems to be 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 30942] New: wrong code at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes (affecting at least as early as 2.9 and later)
https://llvm.org/bugs/show_bug.cgi?id=30942
Bug ID: 30942
Summary: wrong code at -O1 and above on x86_64-linux-gnu in
both 32-bit and 64-bit modes (affecting at least as
early as 2.9 and later)
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ clang -v
clang version 4.0.0 (trunk 286099)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
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.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O0 small.c; ./a.out
$
$ clang -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$
$ clang-2.9 -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$
char a[3];
int b, c, d, e;
unsigned f;
int main ()
{
for (; e < 2; e++)
for (; c; c++)
{
d = e / f;
for (b = 0; b < 3; b++)
a[b + d] = 0;
}
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30943] New: __PRETTY_FUNCTION__ does not use the new c++11 namespace
https://llvm.org/bugs/show_bug.cgi?id=30943
Bug ID: 30943
Summary: __PRETTY_FUNCTION__ does not use the new c++11
namespace
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: csaba.kert...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When __PRETTY_FUNCTION__ creates the function signature, it should use the new
c++11 namespace.
Minimal test case:
#include
#include
std::string foo()
{
printf("%s\n", __PRETTY_FUNCTION__);
return "";
}
int main(int argc, char **argv)
{
foo();
}
When compiled and run with:
- g++ and -D_GLIBCXX_USE_CXX11_ABI=0:
std::string foo()
- g++ and -D_GLIBCXX_USE_CXX11_ABI=1 (default for g++):
std::__cxx11::string foo()
- clang++ (4.0.0-svn286079-1~exp1):
std::string foo()
I think clang should output "std::__cxx11::string foo()", at least for
compatibility with g++.
--
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 30945] New: [AVX512] Failure to flip vector comparison to remove not mask instruction
https://llvm.org/bugs/show_bug.cgi?id=30945
Bug ID: 30945
Summary: [AVX512] Failure to flip vector comparison to remove
not mask instruction
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, elena.demikhov...@intel.com,
igor.bre...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Unearthed by https://reviews.llvm.org/rL286238
define <16 x i32> @test14(<16 x i32>%a, <16 x i32>%b) {
; CHECK-LABEL: test14:
; CHECK: ## BB#0:
; CHECK-NEXT:vpsubd %zmm1, %zmm0, %zmm1
; CHECK-NEXT:vpcmpled %zmm0, %zmm1, %k0
; CHECK-NEXT:knotw %k0, %k1 <-- REMOVED IF WE USED vpcmpgtd INSTEAD
; CHECK-NEXT:vmovdqa32 %zmm1, %zmm0 {%k1} {z}
; CHECK-NEXT:retq
%sub_r = sub <16 x i32> %a, %b
%cmp.i2.i = icmp sgt <16 x i32> %sub_r, %a
%sext.i3.i = sext <16 x i1> %cmp.i2.i to <16 x i32>
%mask = icmp eq <16 x i32> %sext.i3.i, zeroinitializer
%res = select <16 x i1> %mask, <16 x i32> zeroinitializer, <16 x i32> %sub_r
ret <16 x i32>%res
}
define <8 x i64> @test15(<8 x i64>%a, <8 x i64>%b) {
; CHECK-LABEL: test15:
; CHECK: ## BB#0:
; CHECK-NEXT:vpsubq %zmm1, %zmm0, %zmm1
; CHECK-NEXT:vpcmpleq %zmm0, %zmm1, %k0
; CHECK-NEXT:knotw %k0, %k1m <-- REMOVED IF WE USED vpcmpgtq INSTEAD
; CHECK-NEXT:vmovdqa64 %zmm1, %zmm0 {%k1} {z}
; CHECK-NEXT:retq
%sub_r = sub <8 x i64> %a, %b
%cmp.i2.i = icmp sgt <8 x i64> %sub_r, %a
%sext.i3.i = sext <8 x i1> %cmp.i2.i to <8 x i64>
%mask = icmp eq <8 x i64> %sext.i3.i, zeroinitializer
%res = select <8 x i1> %mask, <8 x i64> zeroinitializer, <8 x i64> %sub_r
ret <8 x i64>%res
}
--
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 30946] New: Please update the AMD links under CompilerWriterinfo.html
https://llvm.org/bugs/show_bug.cgi?id=30946 Bug ID: 30946 Summary: Please update the AMD links under CompilerWriterinfo.html Product: Website Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: kiran-kumar.put...@amd.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified In the web page http://llvm.org/docs/CompilerWriterInfo.html When you click on AMD Processor Manuals under X86 it is redirecting to the following link http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html This needs to be fixed and correct link for AMD Processor Manuals is http://developer.amd.com/resources/developer-guides-manuals/ -- 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 30909] LLVM ICE aarch64 -Ofast in Post-RA
https://llvm.org/bugs/show_bug.cgi?id=30909 Evandro Menezes changed: What|Removed |Added Status|NEW |RESOLVED URL||https://reviews.llvm.org/D2 ||6394 Resolution|--- |FIXED --- Comment #3 from Evandro Menezes --- Fixed by https://reviews.llvm.org/rL286231 -- 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 30599] Merge r283129 to 3.9.1
https://llvm.org/bugs/show_bug.cgi?id=30599 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- Merged in r286246. -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30599, which changed state. Bug 30599 Summary: Merge r283129 to 3.9.1 https://llvm.org/bugs/show_bug.cgi?id=30599 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 30946] Please update the AMD links under CompilerWriterinfo.html
https://llvm.org/bugs/show_bug.cgi?id=30946 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED CC||spatel+l...@rotateright.com Resolution|--- |FIXED --- Comment #1 from Sanjay Patel --- https://reviews.llvm.org/rL286249 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30596, which changed state. Bug 30596 Summary: [X86][AVX] Broadcast loads don't respect dependencies https://llvm.org/bugs/show_bug.cgi?id=30596 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 30596] [X86][AVX] Broadcast loads don't respect dependencies
https://llvm.org/bugs/show_bug.cgi?id=30596 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Simon Pilgrim --- Fixed. Merged r282613 at r286248 Merged r283070 at r286251 -- 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 30943] __PRETTY_FUNCTION__ does not use the new c++11 namespace
https://llvm.org/bugs/show_bug.cgi?id=30943 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- There is absolutely no guarantee that two different compilers will produce the same value for __PRETTY_FUNCTION__, and there are plenty of other cases where Clang and G++ will produce different strings. Making our version less pretty doesn't seem in the spirit of the feature :) -- 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 30947] New: movdqa32 being used on a 16-byte aligned address on cannonlake
https://llvm.org/bugs/show_bug.cgi?id=30947
Bug ID: 30947
Summary: movdqa32 being used on a 16-byte aligned address on
cannonlake
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: andrew.b.ad...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I'm getting a case of movdqa32 on a ymm register being used when the address is
only 16-byte aligned. I don't actually have a cannonlake CPU - I'm using
Intel's SDE to emulate one. It faults on this instruction with an alignment
error:
SDE ERROR: TID: 0 executed instruction with an unaligned memory reference to
address 0x1da11770 INSTR: 0x01e4a09e8: IFORM:
VMOVDQA32_MEMu32_MASKmskw_YMMu32_AVX512 :: vmovdqa32 ymmword ptr [rax+rsi*4],
ymm4
Reading the Intel docs, I don't think it's a bug in SDE. movdqa32 requires
alignment to the type being stored, and a ymm register is 32 bytes, not 16.
Here's my test.ll:
define void @fn(<16 x i32> %a1, <16 x i32> %a2, <8 x i32>* %b1, <8 x i32>* %b2,
<8 x i32>* %b3, <8 x i32>* %b4) {
%cmp = icmp slt <16 x i32> %a1, %a2
%mix = select <16 x i1> %cmp, <16 x i32> , <16 x i32>
%lo8 = shufflevector <16 x i32> %mix, <16 x i32> undef, <8 x i32>
store <8 x i32> %lo8, <8 x i32>* %b1, align 8
store <8 x i32> %lo8, <8 x i32>* %b2, align 16
store <8 x i32> %lo8, <8 x i32>* %b3, align 32
store <8 x i32> %lo8, <8 x i32>* %b4, align 64
ret void
}
Compiled with: llc test.ll -mcpu=cannonlake -O3 -filetype=asm -o -
fn: # @fn
# BB#0:
vmovdqa32 (%rdx), %zmm0
movq48(%rsp), %rax
movq40(%rsp), %rdx
vpcmpgtd(%rcx), %zmm0, %k1
vpbroadcastd.LCPI0_0(%rip), %zmm0 {%k1} {z}
vmovdqu32 %ymm0, (%r8)
vmovdqa32 %ymm0, (%r9) /// This instruction should be vmovdqu32
vmovdqa32 %ymm0, (%rdx)
vmovdqa32 %ymm0, (%rax)
retq
--
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 30948] New: clang-cl does not pass -Zc:threadSafeInit- to the fallback compiler
https://llvm.org/bugs/show_bug.cgi?id=30948 Bug ID: 30948 Summary: clang-cl does not pass -Zc:threadSafeInit- to the fallback compiler Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I used gflags to catch cl.exe in a debugger, and I didn't see -Zc:threadSafeInit- in its command line. $ cat foo.cpp #if defined(__clang__) #error Try again #endif $ clang-cl -c -fallback -Zc:threadSafeInit- foo.cpp foo.cpp(2,2): error(clang): Try again #error Try again ^ 1 error generated. clang-cl.exe: warning: falling back to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe [-Wfallback] foo.cpp -- 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 30949] New: clang 4.0 r286254 can't use libstdc++ locales in c++1z mode
https://llvm.org/bugs/show_bug.cgi?id=30949
Bug ID: 30949
Summary: clang 4.0 r286254 can't use libstdc++ locales in c++1z
mode
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: b...@lindev.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
[bero@10cores ~]$ cat test.cc
#include
int main(int argc, char **argv) {
}
[bero@10cores ~]$ clang++ -std=c++1z test.cc
In file included from test.cc:1:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/locale:39:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.h:850:
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:279:5:
error:
explicit instantiation of 'has_facet' does not refer to a function
template, variable
template, member function, member class, or static data member
has_facet >(const locale&);
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:104:5:
note:
candidate template ignored: could not match 'bool (const std::locale &)
throw()'
against 'bool (const std::locale &)'
has_facet(const locale& __loc) throw()
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:291:5:
error:
explicit instantiation of 'has_facet' does not refer to a function
template, variable
template, member function, member class, or static data member
has_facet >(const locale&);
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:104:5:
note:
candidate template ignored: could not match 'bool (const std::locale &)
throw()'
against 'bool (const std::locale &)'
has_facet(const locale& __loc) throw()
^
In file included from test.cc:1:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/locale:40:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.h:2651:
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.tcc:1319:5:
error:
explicit instantiation of 'has_facet' does not refer to a function
template, variable
template, member function, member class, or static data member
has_facet >(const locale&);
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:104:5:
note:
candidate template ignored: could not match 'bool (const std::locale &)
throw()'
against 'bool (const std::locale &)'
has_facet(const locale& __loc) throw()
^
In file included from test.cc:1:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/locale:40:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.h:2651:
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.tcc:1323:5:
error:
explicit instantiation of 'has_facet' does not refer to a function
template, variable
template, member function, member class, or static data member
has_facet >(const locale&);
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:104:5:
note:
candidate template ignored: could not match 'bool (const std::locale &)
throw()'
against 'bool (const std::locale &)'
has_facet(const locale& __loc) throw()
^
In file included from test.cc:1:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/locale:40:
In file included from
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.h:2651:
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_facets.tcc:1327:5:
error:
explicit instantiation of 'has_facet' does not refer to a function
template, variable
template, member function, member class, or static data member
has_facet >(const locale&);
^
/usr/bin/../lib64/gcc/x86_64-mandriva-linux-gnu/6.2.1/../../../../include/c++/6.2.1/bits/locale_classes.tcc:104:5:
note:
candidate template ignored: could not match 'bool (const std::locale &)
throw()'
against 'bool (const std::locale &)'
has_facet(const locale& __loc) throw()
^
In file included from test.cc:1:
In file included from
/usr/bin/../lib
[llvm-bugs] [Bug 30950] New: CFG simplify sinking causes regression for a small testcase
https://llvm.org/bugs/show_bug.cgi?id=30950
Bug ID: 30950
Summary: CFG simplify sinking causes regression for a small
testcase
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: w...@google.com
CC: james.mol...@arm.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
r282453 | rsmith | 2016-09-26 16:49:47 -0700 (Mon, 26 Sep 2016) | 4 lines
P0145R3 (C++17 evaluation order tweaks): consistently emit the LHS of array
subscripting before the RHS, regardless of which is the base and which is the
index.
- 1.c ---
#define MAX(x, y) (((x) > (y)) ? (x) : (y))
long foo(long *maxarray, long k, long size) {
return MAX(maxarray[k], maxarray[k+size+1]);
}
-
For the testcase 1.c above, with and without r282453 llvm generates different
code.
code generated by r282452:
.cfi_startproc
# BB#0: # %entry
movq(%rdi,%rsi,8), %rcx
addq%rsi, %rdx
movq8(%rdi,%rdx,8), %rax
cmpq%rax, %rcx
cmovgeq %rcx, %rax => select from the vals of two array accesses.
retq
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
.cfi_endproc
code generated by r282453:
.cfi_startproc
# BB#0: # %entry
movq(%rdi,%rsi,8), %rax
leaq(%rsi,%rdx), %rcx
leaq1(%rsi,%rdx), %rdx
cmpq8(%rdi,%rcx,8), %rax
cmovgq %rsi, %rdx > select from the indexes of two array accesses.
movq(%rdi,%rdx,8), %rax
retq
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
.cfi_endproc
However, the cause of the change above is CFG simplify sinking. The algorithm
to decide InstructionsToSink in CFG simplify sinking depends on the instruction
sequence, i.e. during the reverse traversal of BB, once an unsinkable
instruction is seen, the traversal will be stopped and remaining sinkable
instruction will not be added into InstructionsToSink. That is why when layout
is changed by r282453, CFG simplify sinking may generate different code.
How the different sinking causes the final code to be different:
Without r282453, CFG simplify sinking generates a select which will select from
the addresses of two array accesses: %arrayidx and %arrayidx2.
define i64 @foo(i64* %maxarray, i64 %k, i64 %size) local_unnamed_addr #0 {
entry:
%arrayidx = getelementptr inbounds i64, i64* %maxarray, i64 %k
%0 = load i64, i64* %arrayidx, align 8, !tbaa !1
%add = add nsw i64 %k, %size
%add1 = add nsw i64 %add, 1
%arrayidx2 = getelementptr inbounds i64, i64* %maxarray, i64 %add1
%1 = load i64, i64* %arrayidx2, align 8, !tbaa !1
%cmp = icmp sgt i64 %0, %1
%arrayidx.arrayidx2 = select i1 %cmp, i64* %arrayidx, i64* %arrayidx2
%2 = load i64, i64* %arrayidx.arrayidx2, align 8, !tbaa !1
ret i64 %2
}
For the IR above, Instcombine can change load(select %arrayidx, %arrayidx2) to
select(%0, %1) and we can remove the last load.
With r282453, CFG simplify sinking generates a select which will select from
the indexes of two array accesses: %k, %add1.
define i64 @foo(i64* %maxarray, i64 %k, i64 %size) local_unnamed_addr #0 {
entry:
%arrayidx = getelementptr inbounds i64, i64* %maxarray, i64 %k
%0 = load i64, i64* %arrayidx, align 8, !tbaa !1
%add = add nsw i64 %k, %size
%add1 = add nsw i64 %add, 1
%arrayidx2 = getelementptr inbounds i64, i64* %maxarray, i64 %add1
%1 = load i64, i64* %arrayidx2, align 8, !tbaa !1
%cmp = icmp sgt i64 %0, %1
%k.add1 = select i1 %cmp, i64 %k, i64 %add1
%arrayidx6 = getelementptr inbounds i64, i64* %maxarray, i64 %k.add1
%2 = load i64, i64* %arrayidx6, align 8, !tbaa !1
ret i64 %2
}
For the IR above, Instcombine can not do the load(select) => select(load)
transformation because the select may be deeply embedded inside of an array
expr like load(...select...), so we cannot eliminate the last load.
In summary, two things to be addressed here:
1. It is better for cfg simplify sinking to generate consistent code for
unrelated changes.
2. Either limit cfg simplify sinking to stop sinking at load address, or extend
instcombine to handle the case load(...select(index1, index2)...) and transform
it to select(load1, load2).
--
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 30929] LibCallsShrinkWrap falsely claims to preserve CFG
https://llvm.org/bugs/show_bug.cgi?id=30929 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Davide Italiano --- r286271 -- 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 30951] New: --reproduce should replace forward slashes with backward slashes inside response files
https://llvm.org/bugs/show_bug.cgi?id=30951 Bug ID: 30951 Summary: --reproduce should replace forward slashes with backward slashes inside response files Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified When we create cpio archives on Windows with --reproduce, the response file contains path with forward slashes, e.g. `D\Dev\LSSDK\` When we try to replay the link invocation via: ld.lld @response.txt, it fails because UNIX only speaks backward slashes for paths. Windows supports both forward and backward slashes just fine, so we might want to do the substitution while processing. We already do this replacement in the cpio file proper anyway. -- 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 30952] New: [polly] Segfault in polly::Scop::addLoopBoundsToHeaderDomain
https://llvm.org/bugs/show_bug.cgi?id=30952
Bug ID: 30952
Summary: [polly] Segfault in
polly::Scop::addLoopBoundsToHeaderDomain
Product: Polly
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
define void @f() {
a:
br i1 undef, label %c, label %b
b:
br label %d
c:
ret void
d:
switch i8 0, label %e [
i8 71, label %d
i8 56, label %d
]
e:
unreachable
}
Crashes with opt -polly-scops -polly-process-unprofitable.
The crash is on the line "int idx = BI->getSuccessor(0) != HeaderBB;" in
polly::Scop::addLoopBoundsToHeaderDomain.
--
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 30953] New: [polly] "Unknowns SCEV was neither parameter nor a valid instruction." UNREACHABLE executed at SCEVAffinator.cpp:553
https://llvm.org/bugs/show_bug.cgi?id=30953
Bug ID: 30953
Summary: [polly] "Unknowns SCEV was neither parameter nor a
valid instruction." UNREACHABLE executed at
SCEVAffinator.cpp:553
Product: Polly
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase (reproduce with opt -polly-process-unprofitable -polly-scops):
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7--linux-android"
@.str.2 = external unnamed_addr constant [2 x i8], align 1
define void @dtbmv_(i32* %n, i32* %k, double* %a, i32* %lda) {
entry:
%0 = load i32, i32* %lda, align 4
%add = add nsw i32 1, %0
%idx.neg = sub i32 0, %add
%add.ptr = getelementptr inbounds double, double* %a, i32 %idx.neg
%call44 = call i32 @lsame_()
%1 = load i32, i32* %k, align 4
%add239 = add nsw i32 %1, 1
%2 = load i32, i32* %n, align 4
br label %for.cond282
for.cond282:
br i1 undef, label %for.body284, label %if.end403.loopexit423
for.body284:
%tobool288 = icmp ne i32 %call44, 0
br i1 %tobool288, label %if.then289, label %if.end294
if.then289:
%mul290 = mul nsw i32 %2, %0
%add291 = add nsw i32 %add239, %mul290
%arrayidx292 = getelementptr inbounds double, double* %add.ptr, i32 %add291
%3 = load double, double* %arrayidx292, align 8
br label %if.end294
if.end294:
unreachable
if.end403.loopexit423:
unreachable
}
declare i32 @lsame_()
Stack trace:
Unknowns SCEV was neither parameter nor a valid instruction.
UNREACHABLE executed at [src]/tools/polly/lib/Support/SCEVAffinator.cpp:553!
#0 0x02a7315c llvm::sys::PrintStackTrace(llvm::raw_ostream&)
[src]/lib/Support/Unix/Signals.inc:402:11
#1 0x02a736b9 PrintStackTraceSignalHandler(void*)
[src]/lib/Support/Unix/Signals.inc:466:1
#2 0x02a705c7 llvm::sys::RunSignalHandlers()
[src]/lib/Support/Signals.cpp:45:5
#3 0x02a73a40 SignalHandler(int)
[src]/lib/Support/Unix/Signals.inc:256:1
#4 0x7f8ca5163330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x7f8ca3b54c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#6 0x7f8ca3b58028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#7 0x029a41b0 LLVMInstallFatalErrorHandler
[src]/lib/Support/ErrorHandling.cpp:133:0
#8 0x02f155b9 polly::SCEVAffinator::visitUnknown(llvm::SCEVUnknown
const*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:554:1
#9 0x02f15fb0 llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:463:16
#10 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#11 0x02f147fb polly::SCEVAffinator::visitAddExpr(llvm::SCEVAddExpr
const*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:389:18
#12 0x02f15ebb llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:451:16
#13 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#14 0x02f149e6 polly::SCEVAffinator::visitMulExpr(llvm::SCEVMulExpr
const*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:398:17
#15 0x02f15edb llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:453:16
#16 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#17 0x02f14796 polly::SCEVAffinator::visitAddExpr(llvm::SCEVAddExpr
const*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:386:16
#18 0x02f15ebb llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:451:16
#19 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#20 0x02f135f7 polly::SCEVAffinator::getPwAff(llvm::SCEV const*,
llvm::BasicBlock*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:146:10
#21 0x02e9c5ab polly::Scop::getPwAff(llvm::SCEV const*,
llvm::BasicBlock*, bool) [src]/tools/polly/lib/Analysis/ScopInfo.cpp:3920:15
#22 0x02e99834 polly::MemoryAccess::getPwAff(llvm::SCEV const*)
[src]/tools/polly/lib/Analysis/ScopInfo.cpp:943:17
#23 0x02e9a207
polly::MemoryAccess::buildAccessRelation(polly::ScopArrayInfo const*)
[src]/tools/polly/lib/Analysis/ScopInfo.cpp:839:17
#24 0x02e9d12d polly::ScopStmt::buildAccessRelations()
[src]/tools/polly/lib/Analysis/ScopInfo.cpp:1116:29
#25 0x02e9f272 polly::ScopStmt::init(llvm::LoopInfo&)
[src]
[llvm-bugs] [Bug 30954] New: [polly] Assertion `S->contains(Expr->getLoop()) && "Scop does not contain the loop referenced in this AddRec"'
https://llvm.org/bugs/show_bug.cgi?id=30954
Bug ID: 30954
Summary: [polly] Assertion `S->contains(Expr->getLoop()) &&
"Scop does not contain the loop referenced in this
AddRec"'
Product: Polly
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase (opt -polly-process-unprofitable -polly-scops):
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7--linux-android"
define void @f(float* %pa, i32* nocapture readonly %lda) {
entry:
switch i8 undef, label %if.then [
i8 78, label %if.else
i8 110, label %if.else
i8 84, label %if.else
i8 116, label %if.else
i8 67, label %if.else
i8 99, label %if.else
]
if.then:
unreachable
if.else:
switch i8 undef, label %polly.stmt.if.then82 [
i8 78, label %polly.stmt.if.end83.region_exiting
i8 110, label %polly.stmt.if.end83.region_exiting
]
for.cond:
%j.0 = phi i32 [ 0, %polly.stmt.if.end83.region_exiting ], [ %inc, %if.end204
]
br i1 undef, label %for.body, label %for.cond.cleanup
for.cond.cleanup:
unreachable
for.body:
%.sroa.speculated592 = select i1 undef, i32 undef, i32 0
%sub119 = sub nsw i32 0, %j.0
%add120 = add nsw i32 %sub119, %.sroa.speculated592
switch i8 undef, label %if.else192 [
i8 78, label %if.then147.critedge
i8 110, label %if.then147.critedge
i8 67, label %0
i8 99, label %0
i8 84, label %if.then181
i8 116, label %if.then181
]
if.then147.critedge:
br label %if.end204
; :0:
unreachable
if.then181:
%mul.i.i.i.i.i442 = mul nsw i32 %2, %j.0
%arrayidx.i.i.i.i.i443 = getelementptr inbounds float, float* %pa, i32
%mul.i.i.i.i.i442
%arrayidx.i.i.i.i.i.i432 = getelementptr inbounds float, float*
%arrayidx.i.i.i.i.i443, i32 %add120
br label %if.else.i.i411
if.else.i.i411:
%1 = load float, float* %arrayidx.i.i.i.i.i.i432, align 4
br i1 false, label %for.body53.i.i420.preheader, label %X
for.body53.i.i420.preheader:
br label %X
X:
unreachable
if.else192:
unreachable
if.end204:
%inc = add nsw i32 %j.0, 1
br label %for.cond
polly.stmt.if.then82:
br label %polly.stmt.if.end83.region_exiting
polly.stmt.if.end83.region_exiting:
%2 = load i32, i32* %lda, align 4
br label %for.cond
}
Stack trace:
opt: [src]/tools/polly/lib/Support/SCEVAffinator.cpp:417: PWACtx
polly::SCEVAffinator::visitAddRecExpr(const llvm::SCEVAddRecExpr *): Assertion
`S->contains(Expr->getLoop()) && "Scop does not contain the loop referenced in
this AddRec"' failed.
#0 0x02a7315c llvm::sys::PrintStackTrace(llvm::raw_ostream&)
[src]/lib/Support/Unix/Signals.inc:402:11
#1 0x02a736b9 PrintStackTraceSignalHandler(void*)
[src]/lib/Support/Unix/Signals.inc:466:1
#2 0x02a705c7 llvm::sys::RunSignalHandlers()
[src]/lib/Support/Signals.cpp:45:5
#3 0x02a73a40 SignalHandler(int)
[src]/lib/Support/Unix/Signals.inc:256:1
#4 0x7f0980208330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x7f097ebf9c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#6 0x7f097ebfd028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#7 0x7f097ebf2bf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#8 0x7f097ebf2ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#9 0x02f14c72
polly::SCEVAffinator::visitAddRecExpr(llvm::SCEVAddRecExpr const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:416:5
#10 0x02f15f1b llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:457:16
#11 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#12 0x02f14796 polly::SCEVAffinator::visitAddExpr(llvm::SCEVAddExpr
const*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:386:16
#13 0x02f15ebb llvm::SCEVVisitor >::visit(llvm::SCEV const*)
[src]/include/llvm/Analysis/ScalarEvolutionExpressions.h:451:16
#14 0x02f1391b polly::SCEVAffinator::visit(llvm::SCEV const*)
[src]/tools/polly/lib/Support/SCEVAffinator.cpp:246:12
#15 0x02f135f7 polly::SCEVAffinator::getPwAff(llvm::SCEV const*,
llvm::BasicBlock*) [src]/tools/polly/lib/Support/SCEVAffinator.cpp:146:10
#16 0x02e9c5ab polly::Scop::getPwAff(llvm::SCEV const*,
llvm::BasicBlock*, bool) [src]/tools/polly/lib/Analysis/ScopInfo.cpp:3920:15
#17 0x02e99834 polly::MemoryAccess::getPwAff(llvm::SCEV const*)
[src]/tools/polly/lib/Analysis/ScopInfo.cpp:943:17
#18 0x02e9a207
polly::MemoryAccess::buildAccessRelation(polly::ScopArrayInfo const*)
[src]/tools/
[llvm-bugs] [Bug 30955] New: Assembler for arm64 ignores padding value of 0 for .balign directive
https://llvm.org/bugs/show_bug.cgi?id=30955 Bug ID: 30955 Summary: Assembler for arm64 ignores padding value of 0 for .balign directive Product: new-bugs Version: 3.8 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jon.n...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When a specific padding value of 0 is passed to a .balign directive in an executable area, the value is ignored and NOP instructions are inserted instead. The value is respected for the .balignw .balignl variants. Further, if a non-zero value is specified, it's respected. Shouldn't an explicit 0 padding value be respected for .balign? Reproducer: // Contents of foo.S .section TestSection, "x" add x14, x14, 0x1 .balign 0x10, 0 add x14, x14, 0x1 .end Command line: clang -target arm64-unknown-linux -c -o foo.o foo.S -- 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 30948] clang-cl does not pass -Zc:threadSafeInit- to the fallback compiler
https://llvm.org/bugs/show_bug.cgi?id=30948 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- r286324 should do it. -- 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 30956] New: [polly] isl_tab_pip.c:508: unbounded optimum
https://llvm.org/bugs/show_bug.cgi?id=30956
Bug ID: 30956
Summary: [polly] isl_tab_pip.c:508: unbounded optimum
Product: Polly
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase (reproduce with opt -polly-process-unprofitable -polly-ast):
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7--linux-android"
define void @f(i8* %p, i32 %fs) {
entry:
%shr8.i320 = ashr i32 undef, 25
%mul.i321 = shl nsw i32 %shr8.i320, 1
%conv39 = trunc i32 %mul.i321 to i8
%conv2.i446 = and i32 %mul.i321, 254
%cmp236.i.i449 = icmp eq i8 %conv39, 0
br label %if.end67
if.end67:
%arrayidx69 = getelementptr inbounds i8, i8* %p, i32 0
br i1 %cmp236.i.i449, label %exit, label %for.body.i596.preheader
for.body.i596.preheader:
br label %for.body.i596
for.body.i596:
%i.016.i586 = phi i32 [ %inc.i594, %for.body.i596 ], [ 1,
%for.body.i596.preheader ]
%arrayidx7.i593 = getelementptr inbounds i8, i8* %arrayidx69, i32 %i.016.i586
store i8 undef, i8* %arrayidx7.i593, align 1
%inc.i594 = add nuw nsw i32 %i.016.i586, 1
%exitcond.i595 = icmp eq i32 %i.016.i586, %conv2.i446
br i1 %exitcond.i595, label %loopexit, label %for.body.i596
loopexit:
br label %exit
exit:
ret void
}
Stack trace:
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:508: unbounded optimum
#0 0x02a7315c llvm::sys::PrintStackTrace(llvm::raw_ostream&)
[src]/llvm/lib/Support/Unix/Signals.inc:402:11
#1 0x02a736b9 PrintStackTraceSignalHandler(void*)
[src]/llvm/lib/Support/Unix/Signals.inc:466:1
#2 0x02a705c7 llvm::sys::RunSignalHandlers()
[src]/llvm/lib/Support/Signals.cpp:45:5
#3 0x02a73a40 SignalHandler(int)
[src]/llvm/lib/Support/Unix/Signals.inc:256:1
#4 0x7fe396b21330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x7fe395512c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#6 0x7fe395516028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#7 0x03776de5 isl_handle_error
[src]/llvm/tools/polly/lib/External/isl/isl_ctx.c:107:1
#8 0x03841451 sol_add
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:507:5
#9 0x03840ec3 find_solutions
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:3976:15
#10 0x03840568 find_solutions_main
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:4078:34
#11 0x0383fec7 basic_map_partial_lexopt_base_sol
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:4204:3
#12 0x03845cba basic_map_partial_lexopt_base_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_tab_pip.c:5516:6
#13 0x0383c045 basic_map_partial_lexopt_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_tab_lexopt_templ.c:159:3
#14 0x0383bf8a isl_tab_basic_map_partial_lexopt_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_tab_lexopt_templ.c:225:2
#15 0x037a497b isl_basic_map_partial_lexopt_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_map_lexopt_templ.c:35:2
#16 0x037b58cd basic_map_partial_lexopt_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_map_lexopt_templ.c:95:3
#17 0x037a4ba0 isl_map_partial_lexopt_aligned_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_map.c:6204:6
#18 0x037a4ac0 isl_map_lexopt_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_map_lexopt_templ.c:204:2
#19 0x037a4d17 isl_map_lexmin_pw_multi_aff
[src]/llvm/tools/polly/lib/External/isl/isl_map_lexopt_templ.c:210:2
#20 0x0375b53e exact_bound
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:475:7
#21 0x0375af14 lower_bounds
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:588:6
#22 0x0375ac8b refine_generic_bounds
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1179:8
#23 0x0375aac2 refine_generic_split
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1287:2
#24 0x0375a8b2 refine_generic
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1313:8
#25 0x0375a3b5 create_node_scaled
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1521:10
#26 0x03759d6e create_node
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1677:3
#27 0x03759c52 add_node
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1812:8
#28 0x0375c595 add_nodes
[src]/llvm/tools/polly/lib/External/isl/isl_ast_codegen.c:1965:16
#29 0x0381f0b6 isl_basic_set_list_call_on_scc
[src]/llvm/tools/polly/lib/External/isl/isl_list_templ.c:382:2
#30 0x0381ef66 isl_basic_set_list_foreach_scc
[src]/llvm/tools/polly/
[llvm-bugs] [Bug 30947] movdqa32 being used on a 16-byte aligned address on cannonlake
https://llvm.org/bugs/show_bug.cgi?id=30947 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Craig Topper --- Fixed in r286342. Thanks for the report. -- 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 30957] New: const is stuck to postfix increment/decrement
https://llvm.org/bugs/show_bug.cgi?id=30957
Bug ID: 30957
Summary: const is stuck to postfix increment/decrement
Product: clang
Version: 3.9
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: blackhors...@mail.ru
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17571
--> https://llvm.org/bugs/attachment.cgi?id=17571&action=edit
formatting options
The following code:
class A
{
A& operator++();
A operator++(int) const;
A& operator--();
A operator--(int) const;
};
is formatted as
class A
{
A& operator++();
A operator++(int)const;
A& operator--();
A operator--(int)const;
};
--
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
