[llvm-bugs] [Bug 38208] New: Huge static analysis performance regression for very simple testcase
https://bugs.llvm.org/show_bug.cgi?id=38208
Bug ID: 38208
Summary: Huge static analysis performance regression for very
simple testcase
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: abramo.bagn...@bugseng.com
CC: llvm-bugs@lists.llvm.org
$ cat p.c
int foo(int a, int b) {
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
a += b; b -= a;
return a + b;
}
$ time scan-build-6.0 gcc -c /tmp/p.c
scan-build: Using '/usr/lib/llvm-6.0/bin/clang' for static analysis
scan-build: Removing directory '/tmp/scan-build-2018-07-18-093847-29397-1'
because it contains no reports.
scan-build: No bugs found.
real0m0,110s
user0m0,058s
sys 0m0,033s
$ time scan-build-7 gcc -c /tmp/p.c
scan-build: Using '/usr/lib/llvm-7/bin/clang' for static analysis
scan-build: Removing directory '/tmp/scan-build-2018-07-18-093759-29380-1'
because it contains no reports.
scan-build: No bugs found.
real0m24,952s
user0m24,912s
sys 0m0,020s
Every single line added to the sequence in source above more than doubles the
execution time.
--
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 38209] New: Scan-build contradicting assumption
https://bugs.llvm.org/show_bug.cgi?id=38209 Bug ID: 38209 Summary: Scan-build contradicting assumption Product: tools Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: analyze Assignee: unassignedb...@nondot.org Reporter: koen.po...@vandewiele.com CC: llvm-bugs@lists.llvm.org Created attachment 20567 --> https://bugs.llvm.org/attachment.cgi?id=20567&action=edit Minimal example illustrating contradicting assumptions Running scan-build-6.0 on the attached code results in contradicting assumptions: Step 2) Assuming 'empty()' is false Step 5) Assuming 'empty()' is true Workaround (enable the WORKAROUND define) allows scan-build to reason about memberPlus100 locally thus avoiding this false positive. Should scan-build be able to reason about this, knowing that both 'empty()' calls should result in the same outcome? -- 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 38210] New: CGObjCGNU - -Woverloaded-virtual warnings
https://bugs.llvm.org/show_bug.cgi?id=38210
Bug ID: 38210
Summary: CGObjCGNU - -Woverloaded-virtual warnings
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: csda...@swan.ac.uk, llvm-bugs@lists.llvm.org,
rjmcc...@apple.com
We're seeing hidden overload warnings on some buildbots:
http://lab.llvm.org:8011/builders/clang-lld-x86_64-2stage/builds/6242/steps/build-stage1-unified-tree/logs/warnings%20%284%29
/home/buildslave/am1i-slv3/clang-lld-x86_64-2stage/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp:587:16:
warning: ‘virtual llvm::Value*
{anonymous}::CGObjCGNU::GetSelector(clang::CodeGen::CodeGenFunction&,
clang::Selector)’ was hidden [-Woverloaded-virtual]
/home/buildslave/am1i-slv3/clang-lld-x86_64-2stage/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp:1345:16:
warning: by ‘virtual llvm::Value*
{anonymous}::CGObjCGNUstep2::GetSelector(clang::CodeGen::CodeGenFunction&,
clang::Selector, const string&)’ [-Woverloaded-virtual]
/home/buildslave/am1i-slv3/clang-lld-x86_64-2stage/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp:589:16:
warning: ‘virtual llvm::Value*
{anonymous}::CGObjCGNU::GetSelector(clang::CodeGen::CodeGenFunction&, const
clang::ObjCMethodDecl*)’ was hidden [-Woverloaded-virtual]
/home/buildslave/am1i-slv3/clang-lld-x86_64-2stage/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp:1345:16:
warning: by ‘virtual llvm::Value*
{anonymous}::CGObjCGNUstep2::GetSelector(clang::CodeGen::CodeGenFunction&,
clang::Selector, const string&)’ [-Woverloaded-virtual]
--
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 38211] New: [RegisterScavenging] Scavenging results in "Using an undefined physical register"
https://bugs.llvm.org/show_bug.cgi?id=38211 Bug ID: 38211 Summary: [RegisterScavenging] Scavenging results in "Using an undefined physical register" Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 20569 --> https://bugs.llvm.org/attachment.cgi?id=20569&action=edit reduced testcase (llc .mir input) This test case involves an MVC (mem-2-mem move) between two spill slots: MVC %stack.180, 0, 16, %stack.1, 0 :: (store 16 into %stack.180, align 8), (load 16 from %stack.1, align 8) PrologEpilogInserter eliminates these frame indexes, and while doing so (since the offset from SP to %stack.1 is too big) a virtual register is created to load SP + 4096: %12:addr64bit = LAY $r15d, 4096, $noreg Then, $r14d is scavenged for %12. This results in: STG killed $r14d, $r15d, 168, $noreg :: (store 8 into %stack.329) $r14d = LAY $r15d, 4096, $noreg MVC $r15d, 1824, 16, killed $r14d, 592 :: (store 16 into %stack.180, align 8), (load 16 from %stack.1, align 8) $r14d = LG $r15d, 168, $noreg :: (load 8 from %stack.329) It seems that $14d was actually not live, so it wouldn't have needed to be spilled and restored: *** Bad machine code: Using an undefined physical register *** - function:main - basic block: %bb.1 bb146 (0x2aa4cf914e8) - instruction: STG killed $r14d, $r15d, 168, $noreg :: (store 8 into %stack.329) - operand 0: killed $r14d LLVM ERROR: Found 1 machine code errors. I am not sure exactly how this works, but it seems that RegScavenger::scavengeRegisterBackwards() has somehow reported that $14d should be spilled, while the MachineVerifier thinks that is not live. bin/llc -mcpu=z13 ./tc_undefpreg_pei.mir -run-pass=prologepilog -verify-machineinstrs -- 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 38195] [regression] _mm_blend_epi16 does not lower to pblendw anymore
https://bugs.llvm.org/show_bug.cgi?id=38195 Gonzalo BG changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Gonzalo BG --- Thanks, that clarifies it. Sorry for the noise. -- 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 38194] [regression] shuffle sequence in _mm256_blend_pd does not lower to vblendpd anymore
https://bugs.llvm.org/show_bug.cgi?id=38194 Gonzalo BG changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Gonzalo BG --- That clarifies it, thanks, and sorry for the noise. -- 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 38212] New: Document new LTO API in LinkTimeOptimization.html
https://bugs.llvm.org/show_bug.cgi?id=38212 Bug ID: 38212 Summary: Document new LTO API in LinkTimeOptimization.html Product: Documentation Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: tejohn...@google.com CC: llvm-bugs@lists.llvm.org The documentation at LinkTimeOptimization.html only talks about the legacy libLTO interface. There isn't any documentation of the new resolution-based LTO interface. That document should be updated to reflect the new API 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 38214] New: clang miscompiles with "-newgvn" at -O2 on valid code
https://bugs.llvm.org/show_bug.cgi?id=38214
Bug ID: 38214
Summary: clang miscompiles with "-newgvn" at -O2 on valid code
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: helloqi...@gmail.com
CC: llvm-bugs@lists.llvm.org
It happens at -O2 and -Os only. I have also tested r334040 and it miscompiles
as well.
$ clang-trunk -v
clang version 7.0.0 (trunk 337366)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ clang-trunk abc.c ; ./a.out
-16
$ clang-trunk -mllvm -enable-newgvn -O3 abc.c ; ./a.out
-16
$ clang-trunk -mllvm -enable-newgvn -O2 abc.c ; ./a.out
0
$ cat abc.c
int printf(char *, ...);
char a, b;
char c[1];
int d, e;
char(f)(char g, char h) { return g + h; }
int __attribute__((noinline)) i(long g) { return g ? 1 : 0; }
int main() {
char j = 0;
for (; j != 15; j = f(j, 5)) {
a = 0;
for (; a < 11; ++a)
if (a == b && j) {
e = 0;
for (; e < 8; e++)
if (i((long)c))
--d;
}
}
printf("%d\n", d);
}
--
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 38215] New: boolean && misformatted inside template parameter list
https://bugs.llvm.org/show_bug.cgi?id=38215 Bug ID: 38215 Summary: boolean && misformatted inside template parameter list Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: dch...@google.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org This snippet should be formatted as: template ::value && std::is_move_assignable::value> class MoveOnly; But locally, it seems to be getting formatted as: template ::value&& std::is_move_assignable::value> class MoveOnly; -- 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 38216] New: No ::nullptr_t in header
https://bugs.llvm.org/show_bug.cgi?id=38216
Bug ID: 38216
Summary: No ::nullptr_t in header
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
clang++ rejects the following code:
#include
::nullptr_t n;
"3|error: 'nullptr_t' in namespace '::' does not name a type"
This code is supposed to be accepted, because [depr.c.headers] p2 says:
"Every C header, each of which has a name of the form name.h, behaves as if
each name placed in the standard library namespace by the corresponding cname
header is placed within the global namespace scope."
Paolo Carlini has suggested to perform this change near to existing C++11-aware
code in stddef.h:
#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \
|| (defined(__cplusplus) && __cplusplus >= 201103L)
#ifndef _GCC_MAX_ALIGN_T
#define _GCC_MAX_ALIGN_T
/* Type whose alignment is supported in every context and is at least
as great as that of any standard type not using alignment
specifiers. */
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld __attribute__((__aligned__(__alignof__(long
double;
} max_align_t;
#endif
#endif /* C11 or C++11. */
BTW, I tried g++. It accepts the above code sample.
--
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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 9251, which changed state. Bug 9251 Summary: Support -fno-delete-null-pointer-checks https://bugs.llvm.org/show_bug.cgi?id=9251 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 9251] Support -fno-delete-null-pointer-checks
https://bugs.llvm.org/show_bug.cgi?id=9251 Manoj Gupta changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||manojgu...@google.com Assignee|unassignedclangbugs@nondot. |manojgu...@google.com |org | --- Comment #5 from Manoj Gupta --- Support added in: https://reviews.llvm.org/rL336613 https://reviews.llvm.org/rL337433 -- 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 37878] [Modules] Auto loading of modulemap in subdirectories
https://bugs.llvm.org/show_bug.cgi?id=37878 Yuka Takahashi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Yuka Takahashi --- Cool! Closing) -- 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 38217] New: Clang/LLVM optimizes division and modulo worse than MSVC, part 2
https://bugs.llvm.org/show_bug.cgi?id=38217
Bug ID: 38217
Summary: Clang/LLVM optimizes division and modulo worse than
MSVC, part 2
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20570
--> https://bugs.llvm.org/attachment.cgi?id=20570&action=edit
Test case
This appears to be a different bug than
https://bugs.llvm.org/show_bug.cgi?id=37983 "Clang/LLVM optimizes division and
modulo worse than MSVC" (which is probably a duplicate of
https://bugs.llvm.org/show_bug.cgi?id=23106 "Division followed by modulo
generates longer machine code than vice versa") because it involves modulo
followed by division.
This affects the Ryu algorithm for printing floating-point numbers
(https://github.com/ulfjack/ryu ) and therefore affects C++17 floating-point
std::to_chars().
I observe that MSVC's codegen is unaffected by WORKAROUND, while Clang/LLVM
generates less assembly code (which is faster when profiled in the real
algorithm) for WORKAROUND.
Here's a Godbolt link demonstrating the codegen difference (this isn't
Windows-specific): https://godbolt.org/g/uX1AD8
C:\Temp\TESTING_X64>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.26504 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp\TESTING_X64>clang-cl -m64 -v
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\msvc\src\vctools\NonShip\ClangLLVM\bin
C:\Temp\TESTING_X64>type d2s.cpp
#include
#include
static const char DIGIT_TABLE[] =
"0001020304050607080910111213141516171819"
"2021222324252627282930313233343536373839"
"4041424344454647484950515253545556575859"
"6061626364656667686970717273747576777879"
"8081828384858687888990919293949596979899";
void d2s_buffered(uint64_t output, char * result) {
uint32_t i = 0;
while (output >= 1) {
#ifdef WORKAROUND
const uint32_t c = (uint32_t) (output - 1 * (output / 1));
#else
const uint32_t c = (uint32_t) (output % 1);
#endif
output /= 1;
const uint32_t c0 = (c % 100) << 1;
const uint32_t c1 = (c / 100) << 1;
memcpy(result - i - 1, DIGIT_TABLE + c0, 2);
memcpy(result - i - 3, DIGIT_TABLE + c1, 2);
i += 4;
}
}
C:\Temp\TESTING_X64>cl /EHsc /nologo /W4 /MT /O2 /c d2s.cpp /FAsc
/Famsvc_workaround.cod /DWORKAROUND
d2s.cpp
C:\Temp\TESTING_X64>cl /EHsc /nologo /W4 /MT /O2 /c d2s.cpp /FAsc
/Famsvc_modulo.cod
d2s.cpp
C:\Temp\TESTING_X64>git diff msvc_workaround.cod msvc_modulo.cod
diff --git a/msvc_workaround.cod b/msvc_modulo.cod
index 1be1419..aff234c 100644
--- a/msvc_workaround.cod
+++ b/msvc_modulo.cod
@@ -86,11 +86,11 @@ $LL2@d2s_buffer:
; 15 : #ifdef WORKAROUND
; 16 : const uint32_t c = (uint32_t) (output - 1 * (output /
1));
+; 17 : #else^M
+; 18 : const uint32_t c = (uint32_t) (output % 1);^M
0003048 8b c7 mov rax, rdi
-; 17 : #else
-; 18 : const uint32_t c = (uint32_t) (output % 1);
; 19 : #endif
; 20 :
; 21 : output /= 1;
C:\Temp\TESTING_X64>clang-cl -m64 /EHsc /nologo /W4 /MT /O2 /c d2s.cpp /FA
/Faclang_workaround.asm /DWORKAROUND
C:\Temp\TESTING_X64>clang-cl -m64 /EHsc /nologo /W4 /MT /O2 /c d2s.cpp /FA
/Faclang_modulo.asm
C:\Temp\TESTING_X64>git diff clang_workaround.asm clang_modulo.asm
diff --git a/clang_workaround.asm b/clang_modulo.asm
index 2a8cb49..6026638 100644
--- a/clang_workaround.asm
+++ b/clang_modulo.asm
@@ -29,19 +29,22 @@
movq%r9, %rax
mulq%r10
shrq$11, %rdx
- imulq $-1, %rdx, %rax # imm = 0xD8F0
- addq%r9, %rax
- movl%eax, %esi
- imulq $1374389535, %rsi, %rsi # imm = 0x51EB851F
- shrq$37, %rsi
- imull $100, %esi, %edi
- subl%edi, %eax
+ imulq $1, %rdx, %rax # imm = 0x2710
+ movq%r9, %rsi
+ subq%rax, %rsi
+ imulq $1374389535, %rsi, %rax # imm = 0x51EB851F
+ movq%rax, %rdi
+ shrq$37, %rdi
+ imull $100, %edi, %edi
+ subl%edi, %esi
+ shrq$36, %rax
+ andl$510, %eax # imm = 0x1FE
movl%ecx, %edi
movq%r8, %rbx
subq%rdi, %rbx
- movzwl (%r11,%rax,2), %eax
- movw%ax, -1(%rbx)
- movzwl (%r11,%rsi,2), %eax
+ movzwl (%r11,%rsi,2), %esi
+ movw%si, -1(%rbx)
+ movzwl (%rax,%r11), %eax
movw%ax, -3(%rbx)
addl$4, %ecx
cmpq$, %r9 # imm = 0x5F5E0FF
-
[llvm-bugs] [Bug 38218] New: ISL: "spaces don't match"
https://bugs.llvm.org/show_bug.cgi?id=38218 Bug ID: 38218 Summary: ISL: "spaces don't match" Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: isl Assignee: polly-...@googlegroups.com Reporter: wich...@vitalitystudios.com CC: llvm-bugs@lists.llvm.org Created attachment 20575 --> https://bugs.llvm.org/attachment.cgi?id=20575&action=edit bugpoint Reproduce with `opt bugpoint-reduced-simplified.bc -scoped-noalias -inline -loop-rotate -gvn -memcpyopt -jump-threading -instcombine -polly-codegen -simplifycfg -o /dev/null`. Backtrace: #0 0x7f8665984e97 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f8665986801 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x04b534a1 in isl_handle_error (ctx=0x5e365d0, error=isl_error_invalid, msg=0x8921b1 "spaces don't match", file=0xe409cc "llvm/tools/polly/lib/External/isl/isl_map.c", line=7715) at llvm/tools/polly/lib/External/isl/isl_ctx.c:118 #3 0x04b9b15a in map_union_disjoint (map1=0x5ed4650, map2=0x5eca6b0) at llvm/tools/polly/lib/External/isl/isl_map.c:7714 #4 0x04b9b44b in map_union_aligned (map1=0x5ed4650, map2=0x5eca6b0) at llvm/tools/polly/lib/External/isl/isl_map.c:7813 #5 0x04b8c000 in isl_map_align_params_map_map_and (map1=0x5ed4650, map2=0x5eca6b0, fn=0x4b9b3d0 ) at llvm/tools/polly/lib/External/isl/isl_map.c:1392 #6 0x04b9af44 in isl_map_union (map1=0x5ed4040, map2=0x5ecc4e0) at llvm/tools/polly/lib/External/isl/isl_map.c:7831 #7 0x04b9b532 in isl_set_union (set1=0x5ed4040, set2=0x5ecc4e0) at llvm/tools/polly/lib/External/isl/isl_map.c:7843 #8 0x042b3c40 in isl::noexceptions::set::unite (this=0x5e9de98, set2=...) at llvm/tools/polly/lib/External/isl/include/isl/isl-noexceptions.h:14276 #9 0x042943d7 in getPwAff (S=..., BB=0x5ecdf60, InvalidDomainMap=..., E=0x5eafdb0, NonNegative=false) at llvm/tools/polly/lib/Analysis/ScopInfo.cpp:1415 #10 0x0429553d in buildConditionSets (S=..., BB=0x5ecdf60, Condition=0x5ec9080, TI=0x0, L=0x0, Domain=0x5e30af0, InvalidDomainMap=..., ConditionSets=...) at llvm/tools/polly/lib/Analysis/ScopInfo.cpp:1599 #11 0x04298ca6 in polly::Scop::addUserAssumptions (this=0x5ea6c60, AC=..., DT=..., LI=..., InvalidDomainMap=...) at llvm/tools/polly/lib/Analysis/ScopInfo.cpp:2068 #12 0x043aac60 in polly::ScopBuilder::buildScop (this=0x7fff2c836568, R=..., AC=..., ORE=...) at llvm/tools/polly/lib/Analysis/ScopBuilder.cpp:1519 #13 0x043abc52 in polly::ScopBuilder::ScopBuilder (this=0x7fff2c836568, R=0x5ec9320, AC=..., AA=..., DL=..., DT=..., LI=..., SD=..., SE=..., ORE=...) at llvm/tools/polly/lib/Analysis/ScopBuilder.cpp:1612 #14 0x042a9937 in polly::ScopInfoRegionPass::runOnRegion (this=0x5e286c0, R=0x5ec9320, RGM=...) at llvm/tools/polly/lib/Analysis/ScopInfo.cpp:5028 #15 0x02c1f008 in llvm::RGPassManager::runOnFunction (this=0x5e28c80, F=...) at llvm/lib/Analysis/RegionPass.cpp:97 #16 0x03484b27 in llvm::FPPassManager::runOnFunction (this=0x5dec420, F=...) at llvm/lib/IR/LegacyPassManager.cpp:1585 #17 0x02a37e7e in (anonymous namespace)::CGPassManager::RunPassOnSCC (this=0x5ddf2b0, P=0x5dec420, CurSCC=..., CG=..., CallGraphUpToDate=@0x7fff2c836e9e: true, DevirtualizedCall=@0x7fff2c836f43: false) at llvm/lib/Analysis/CallGraphSCCPass.cpp:162 #18 0x02a377bd in (anonymous namespace)::CGPassManager::RunAllPassesOnSCC (this=0x5ddf2b0, CurSCC=..., CG=..., DevirtualizedCall=@0x7fff2c836f43: false) at llvm/lib/Analysis/CallGraphSCCPass.cpp:426 #19 0x02a37061 in (anonymous namespace)::CGPassManager::runOnModule (this=0x5ddf2b0, M=...) at llvm/lib/Analysis/CallGraphSCCPass.cpp:482 #20 0x0348564c in (anonymous namespace)::MPPassManager::runOnModule (this=0x5de6460, M=...) at llvm/lib/IR/LegacyPassManager.cpp:1664 #21 0x03485123 in llvm::legacy::PassManagerImpl::run (this=0x5de6740, M=...) at llvm/lib/IR/LegacyPassManager.cpp:1768 #22 0x03485b81 in llvm::legacy::PassManager::run (this=0x7fff2c837a20, M=...) at llvm/lib/IR/LegacyPassManager.cpp:1799 #23 0x02121efe in main (argc=13, argv=0x7fff2c838238) at llvm/tools/opt/opt.cpp:810 #24 0x7f8665967b97 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #25 0x020e202a in _start () -- 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
