[llvm-bugs] [Bug 33022] Options '-optimize-regalloc=false -regalloc=greedy' allowed and failing
https://bugs.llvm.org/show_bug.cgi?id=33022 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jonas Paulsson --- r303238 -- 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 33066] New: Several OpenMP tests fail with stack trace
https://bugs.llvm.org/show_bug.cgi?id=33066 Bug ID: 33066 Summary: Several OpenMP tests fail with stack trace Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: marvin_schm...@gmx.net CC: llvm-bugs@lists.llvm.org Created attachment 18453 --> https://bugs.llvm.org/attachment.cgi?id=18453&action=edit test failures 4.0.0 as well as 4.0.1rc1 fail several OpenMP-related tests with a stack trace. trunk/master HEAD passes all tests, so it seems it's just a matter of backporting the right commit(s), but I couldn't find an obvious suspect from a cursory look. I'm sure somebody else will know what's causing this from a quick glance. Shortened test log is attached -- 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 33068] New: -Wunneeded-internal-declaration disregards sizeof(x)
https://bugs.llvm.org/show_bug.cgi?id=33068
Bug ID: 33068
Summary: -Wunneeded-internal-declaration disregards sizeof(x)
Product: clang
Version: 3.6
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ste...@bytereef.org
CC: llvm-bugs@lists.llvm.org
$ clang --version
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on
LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ cat test.c
static int x = 10;
int
main(void)
{
return sizeof(x) == 4;
}
$ clang -Wall -Wextra -Werror -o test test.c
test.c:1:12: error: variable 'x' is not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]
static int x = 10;
^
1 error generated.
--
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 33069] New: "drops <> qualifiers" message on obj-c++ code with ARC
https://bugs.llvm.org/show_bug.cgi?id=33069
Bug ID: 33069
Summary: "drops <> qualifiers" message on obj-c++ code
with ARC
Product: clang
Version: unspecified
Hardware: Macintosh
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: w...@iki.fi
CC: llvm-bugs@lists.llvm.org
This is more a cosmetic flaw in a compiler error message than anything else,
but anyways. Consider the following minimal piece of Objective-C++ code:
//---
#import "Foundation/Foundation.h"
@interface Test:NSObject @end
@implementation Test
- (void) foo: (NSString*&) s {}
- (void) bar { NSString* s; [self foo:s]; }
@end
//---
When ARC is enabled (-fobjc-arc), clang issues the following error:
test.mm:8:39: error: binding value of type 'NSString *__strong' to reference to
type 'NSString *__autoreleasing' drops <> qualifiers
I believe that "<>" to be some kind of indication of a bug somewhere in
the compile-time error reporting code.
clang reports the following version information:
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
--
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 33070] New: Merge r303257 into 4.0.1: fix register save offsets (PR26519)
https://bugs.llvm.org/show_bug.cgi?id=33070 Bug ID: 33070 Summary: Merge r303257 into 4.0.1: fix register save offsets (PR26519) Product: libraries Version: 4.0 Hardware: PC URL: https://reviews.llvm.org/rL303257 OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: kparz...@codeaurora.org CC: llvm-bugs@lists.llvm.org Blocks: 32061 This is needed for FreeBSD/ppc32. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=32061 [Bug 32061] [meta] 4.0.1 Release Blockers -- 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 33062] [OPENMP] positive loop step not recognized as such
https://bugs.llvm.org/show_bug.cgi?id=33062 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Alexey Bataev --- The error message is correct here: 0u-1u is 4294967295 (because it is unsigned), so you're not incrementing the loop counter. -- 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 33071] New: Assertion in register allocation on ARM
https://bugs.llvm.org/show_bug.cgi?id=33071
Bug ID: 33071
Summary: Assertion in register allocation on ARM
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18454
--> https://bugs.llvm.org/attachment.cgi?id=18454&action=edit
Test case
The IR attached causes an assertion in LLC on at least 3.9 and 4.0.
The failure is
```
llc:
/home/yuyichao/projects/julia/tests/master/deps/srccache/llvm-4.0.0/lib/CodeGen/VirtRegMap.cpp:443:
void {anonymous}::VirtRegRewriter::rewrite(): Assertion `PhysReg && "Invalid
SubReg for physical register"' failed.
```
Which is triggered on `%D16 = COPY %vreg29:ssub_0; DPR:%vreg29`.
Enclosing BB
```
400BBB#1: derived from LLVM BB %if
Live Ins: %R4 %R5 %R8 %R9 %S16
Predecessors according to CFG: BB#0
416B%D16 = FCONSTD 128, pred:14, pred:%noreg;
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
432B%D17 = VCVTDS %S16, pred:14, pred:%noreg;
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
448B%D16 = VADDD %D17, %D16, pred:14, pred:%noreg;
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
464B%R10, %R7 = VMOVRRD %D16, pred:14, pred:%noreg;
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
480B%R0 = MOVi 1, pred:14, pred:%noreg, opt:%noreg
512B%D16 = COPY %vreg29:ssub_0; DPR:%vreg29
560BB ;
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
Successors according to CFG: BB#4(?%)
```
Enclosing BB before `rewrite`
```
BB#1: derived from LLVM BB %if
Live Ins: %R4 %R5 %R8 %R9 %S16
Predecessors according to CFG: BB#0
%vreg27 = FCONSTD 128, pred:14, pred:%noreg; DPR:%vreg27
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
%vreg28 = VCVTDS %vreg17, pred:14, pred:%noreg; DPR:%vreg28
SPR:%vreg17 dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
%vreg29 = VADDD %vreg28, %vreg27, pred:14,
pred:%noreg; DPR:%vreg29,%vreg28,%vreg27
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
%vreg6, %vreg5 = VMOVRRD %vreg29, pred:14, pred:%noreg;
GPR:%vreg6,%vreg5 DPR:%vreg29
dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
%vreg72 = MOVi 1, pred:14, pred:%noreg, opt:%noreg; GPR:%vreg72
%vreg67 = COPY %vreg29:ssub_0; DPR:%vreg67,%vreg29
B ; dbg:/home/yuyichao/projects/julia/tests/master/script.jl:2
Successors according to CFG: BB#4(?%)
```
Ref https://github.com/JuliaLang/julia/issues/21926
--
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 33072] New: Exponential code growth while inlining internal functions
https://bugs.llvm.org/show_bug.cgi?id=33072 Bug ID: 33072 Summary: Exponential code growth while inlining internal functions Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: arie...@mail.tau.ac.il CC: llvm-bugs@lists.llvm.org Created attachment 18456 --> https://bugs.llvm.org/attachment.cgi?id=18456&action=edit File running 4^7 iterations of Collatz's Conjecture, which expands to 45kLoIR It appears that under some situations I don't fully understand (e.g. the attached example, which expands to over 45k lines of IR), LLVM can "deeply inline" a tree of internal functions, causing exponential IR growth. ## Meta This was originally reported as https://github.com/rust-lang/rust/issues/41696. Confirmed on Rust's LLVM 4.0 and Debian's LLVM 3.9 - I don't have a trunk LLVM ready right now. ## STR $ wc -l sloline.cu.ll 83 sloline.cu.ll $ opt -S -inline sloline.cu.ll | wc -l 45068 $ -- 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 33073] New: PowerPC: Invalid code generation causing SEGV
https://bugs.llvm.org/show_bug.cgi?id=33073
Bug ID: 33073
Summary: PowerPC: Invalid code generation causing SEGV
Product: clang
Version: 4.0
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: andyg1...@hotmail.co.uk
CC: llvm-bugs@lists.llvm.org
Created attachment 18457
--> https://bugs.llvm.org/attachment.cgi?id=18457&action=edit
Output generated by clang 4.0
I have recently upgraded from clang 3.8 to 4.0, and I am now getting
segmentation fault crashes in compiled code for PowerPC 603e.
I have narrowed the crash to a particular function in the sqlite3 library that
I am using. The following code is where the segmentation fault occurs, and the
line marked "uncomment this line" eradicates the problem. The complete
software application built around this then works seemingly perfectly (albeit
producing a lot of unwanted console output!), although I may simply not be
triggering the problem if it exists elsewhere. The code generation of this
function, however, seems reliably broken.
This is the code fragment from sqlite3:
__attribute__ ((noinline))
/*SQLITE_PRIVATE*/ i64 sqlite3VdbeIntValue(Mem *pMem){
int flags;
assert( pMem->db==0 || sqlite3_mutex_held(pMem->db->mutex) );
assert( EIGHT_BYTE_ALIGNMENT(pMem) );
flags = pMem->flags;
if( flags & MEM_Int ){
// puts("xyz"); // <- uncomment this line "fixes" the compile
return pMem->u.i;
}else if( flags & MEM_Real ){
return doubleToInt64(pMem->r);
}else if( flags & (MEM_Str|MEM_Blob) ){
i64 value = 0;
assert( pMem->z || pMem->n==0 );
testcase( pMem->z==0 );
sqlite3Atoi64(pMem->z, &value, pMem->n, pMem->enc);
return value;
}else{
return 0;
}
}
I changed the function to non-inlined so that its presence in the compiler
output was easy to find. It makes no difference to the validity of the
generated executable.
I have attached four fragments of the compiler output, both for the "working"
version (with the puts line) and the broken version (without), and then both
for llvm output and ppc assembly output. I have trimmed out the majority of
these files since the files are tens of kilobytes, but I have left in the parts
where the differences in output exist.
In case it is helpful, I am compiling with -O2 and -fPIC.
I will attempt to rebuild the 3.8 compiler and check the output generated by
this for differences. If I succeed, I will upload this too.
Cheers,
Andy
--
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 33074] New: Rematerialized LEApcrel can address a different literal pool from the original
https://bugs.llvm.org/show_bug.cgi?id=33074
Bug ID: 33074
Summary: Rematerialized LEApcrel can address a different
literal pool from the original
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: john.brawn@gmail.com
CC: llvm-bugs@lists.llvm.org
When we have an LEApcrel instruction that gets rematerialized, if the
rematerialization point is far enough away from the original then the literal
pool for the first LEApcrel will be emitted before we get to the second
LEApcrel causing the second LEApcrel to be redirected to a new literal pool
which will be emitted later. This means the two LEApcrel instructions give
different values, which can lead to incorrect program behaviour in some cases.
An example:
file1.c:
#include
static const char *staticstr = 0;
void otherfn1(const char *p, const char *q)
{
if (p != staticstr) printf("p != staticstr\n");
if (q != staticstr+8) printf("q != staticstr+8\n");
}
void otherfn2(const char *p)
{
staticstr = p;
}
void filler(void)
{
}
file2.c:
void otherfn1(const char *p, const char *q);
void otherfn2(const char *p);
void filler(void);
void fn(int *p)
{
const char *str = "expected";
otherfn2(str);
// Use up a load of registers, causing str to spill
int arr[8];
arr[0] = p[0];
arr[1] = p[10];
arr[2] = p[20];
arr[3] = p[30];
arr[4] = p[40];
arr[5] = p[50];
arr[6] = p[60];
arr[7] = p[70];
filler();
p[0] = arr[0];
p[10] = arr[1];
p[20] = arr[2];
p[30] = arr[3];
p[40] = arr[4];
p[50] = arr[5];
p[60] = arr[6];
p[70] = arr[7];
// Add a load of filler to make the literal pool out of range
#define FILLER8 filler(); filler(); filler(); filler(); filler(); filler();
filler(); filler();
#define FILLER64 FILLER8; FILLER8; FILLER8; FILLER8; FILLER8; FILLER8;
FILLER8; FILLER8;
#define FILLER512 FILLER64; FILLER64; FILLER64; FILLER64; FILLER64; FILLER64;
FILLER64; FILLER64;
FILLER512;
FILLER512;
otherfn1(str, str+8);
}
int main()
{
int arr[80];
fn(arr);
return 0;
}
Compiled with -mcpu=cortex-a15 -mthumb -O2 we get the output
p != staticstr
q != staticstr+8
because for the call to otherfn1 the LEApcrel of "expected" has been
rematerialized, causing the address to be different to the call to otherfn2.
--
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 33075] New: Assignment to struct passed by value modifies caller's stack frame
https://bugs.llvm.org/show_bug.cgi?id=33075
Bug ID: 33075
Summary: Assignment to struct passed by value modifies caller's
stack frame
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gergo.bar...@inria.fr
CC: llvm-bugs@lists.llvm.org
Created attachment 18458
--> https://bugs.llvm.org/attachment.cgi?id=18458&action=edit
Input C file for triggering the bug
Consider the following C program (also in the attachment):
$ cat bug_06.c
struct S1 {
int f4;
int f8;
int pad[3];
};
int func(struct S1 s)
{
s.f8 = 666;
return s.f4;
}
The struct is passed into the function by value, and the store to s.f8 should
only affect the function's local copy. (And be optimized away because it is
dead.) However, LLVM seems to generate code that modifies the caller's copy on
the stack:
$ clang bug_06.c -O3 -S -o -.text
.file "bug_06.c"
.globl func
.p2align4, 0x90
.type func,@function
func: # @func
.cfi_startproc
# BB#0:
movl$666, 12(%rsp) # imm = 0x29A
movl8(%rsp), %eax
retq
.Lfunc_end0:
.size func, .Lfunc_end0-func
.cfi_endproc
.ident "clang version 5.0.0 (trunk 303270)"
.section".note.GNU-stack","",@progbits
Note the store of 666 to an address on the stack although no stack frame was
allocated, i.e., to an address in the caller's frame.
This may be a duplicate of https://bugs.llvm.org/show_bug.cgi?id=10485 , which
was not investigated further because it seemed to be a bug in the bitcode
interpreter.
--
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 33075] Assignment to struct passed by value modifies caller's stack frame
https://bugs.llvm.org/show_bug.cgi?id=33075
Reid Kleckner changed:
What|Removed |Added
CC||r...@google.com
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Reid Kleckner ---
This is correct behavior. The caller should not expect arguments passed in
memory to retain their original values, just as it would not expect the
argument registers to be preserved.
GCC does the same thing:
https://godbolt.org/g/vZybVN
I had to modify the example to escape 's' to preserve the dead store of 666.
ABIs have been this way forever. Legacy ABIs (32-bit x86) pass all arguments in
memory, and for those ABIs, compilers typically store to argument memory at
-O0. They don't do a copy.
Consider:
$ echo 'void f(int a) { ++a; }' | gcc -x c - -m32 -S -o -
.file ""
.text
.globl _f
.def_f; .scl2; .type 32; .endef
_f:
pushl %ebp
movl%esp, %ebp
addl$1, 8(%ebp)
nop
popl%ebp
--
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 33077] New: [Loop Reduce] Assertion failure due to invalid canonicalization for formula
https://bugs.llvm.org/show_bug.cgi?id=33077 Bug ID: 33077 Summary: [Loop Reduce] Assertion failure due to invalid canonicalization for formula Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: a...@azul.com CC: llvm-bugs@lists.llvm.org Created attachment 18459 --> https://bugs.llvm.org/attachment.cgi?id=18459&action=edit Input IR for loop-reduce Testcase causing an assertion failure in formula canonicalization in LSR. This was added in patch: https://reviews.llvm.org/rL295884 Assertion failed: (F.isCanonical(L) && "Invalid canonical representation"), function InsertFormula, Transforms/Scalar/LoopStrengthReduce.cpp, line 1431 Added a test case reduced using bugpoint. By reverting rL295884, the test case passes. Reproduce: opt -loop-reduce bugpoint.ll -- 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 33078] New: wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://bugs.llvm.org/show_bug.cgi?id=33078
Bug ID: 33078
Summary: wrong code at -Os and above on x86_64-linux-gnu (in
both 32-bit and 64-bit modes)
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 5.0.0 (trunk 303218)
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/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4
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.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.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.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O1 small.c; ./a.out
$ clang-4.0.0 -Os small.c; ./a.out
$
$ clang -Os small.c
$ ./a.out
Aborted (core dumped)
$
---
unsigned b;
int c, d;
short e (int f, int g)
{
return f * g;
}
char h (int f)
{
return f;
}
int main ()
{
short a = e (!c, 65535);
b = d = h (a <= -1);
if (b != 1)
__builtin_abort ();
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 33079] New: [RA] Crash in SlotIndex::getIndex()
https://bugs.llvm.org/show_bug.cgi?id=33079 Bug ID: 33079 Summary: [RA] Crash in SlotIndex::getIndex() Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org, ma...@braunis.de, qcolom...@apple.com The input IR crashes in SlotIndex if invoked with the following: ./llc -opt-bisect-limit=19 ren.ll Relevant stacktrace: #3 0x7ff6f048dc30 __restore_rt (/lib64/libpthread.so.0+0x10c30) #4 0x0146d5f9 llvm::SlotIndex::getIndex() const /home/davide/work/llvm/build-rel-noassert/../include/llvm/CodeGen/SlotIndexes.h:118:0 #5 0x0146d5f9 llvm::SlotIndex::operator>=(llvm::SlotIndex) const /home/davide/work/llvm/build-rel-noassert/../include/llvm/CodeGen/SlotIndexes.h:186:0 #6 0x0146d5f9 llvm::LiveRange::find(llvm::SlotIndex) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/LiveInterval.cpp:340:0 #7 0x0165fc79 llvm::LiveRange::FindSegmentContaining(llvm::SlotIndex) const /home/davide/work/llvm/build-rel-noassert/../include/llvm/CodeGen/LiveInterval.h:425:0 #8 0x0165fc79 llvm::LiveRange::getVNInfoAt(llvm::SlotIndex) const /home/davide/work/llvm/build-rel-noassert/../include/llvm/CodeGen/LiveInterval.h:404:0 #9 0x0165fc79 spillAroundUses /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/InlineSpiller.cpp:914:0 #10 0x0165fc79 spillAll /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/InlineSpiller.cpp:996:0 #11 0x0165fc79 (anonymous namespace)::InlineSpiller::spill(llvm::LiveRangeEdit&) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/InlineSpiller.cpp:1045:0 #12 0x0157f25b setStage /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocGreedy.cpp:225:0 #13 0x0157f25b (anonymous namespace)::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&, llvm::SmallVectorImpl&, llvm::SmallSet >&, unsigned int) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocGreedy.cpp:2623:0 #14 0x01581681 (anonymous namespace)::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl&) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocGreedy.cpp:2285:0 #15 0x0168608d llvm::RegAllocBase::allocatePhysRegs() /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocBase.cpp:111:0 #16 0x0157cede llvm::SmallVectorTemplateCommon::end() /home/davide/work/llvm/build-rel-noassert/../include/llvm/ADT/SmallVector.h:119:0 #17 0x0157cede llvm::SetVector, llvm::SmallDenseSet > >::end() /home/davide/work/llvm/build-rel-noassert/../include/llvm/ADT/SetVector.h:94:0 #18 0x0157cede tryHintsRecoloring /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocGreedy.cpp:2528:0 #19 0x0157cede (anonymous namespace)::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/RegAllocGreedy.cpp:2743:0 #20 0x014d5af9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/davide/work/llvm/build-rel-noassert/../lib/CodeGen/MachineFunctionPass.cpp:62:0 #21 0x017440f1 llvm::FPPassManager::runOnFunction(llvm::Function&) /home/davide/work/llvm/build-rel-noassert/../lib/IR/LegacyPassManager.cpp:1519:0 #22 0x01744193 llvm::FPPassManager::runOnModule(llvm::Module&) /home/davide/work/llvm/build-rel-noassert/../lib/IR/LegacyPassManager.cpp:1540:0 #23 0x01744ae0 runOnModule /home/davide/work/llvm/build-rel-noassert/../lib/IR/LegacyPassManager.cpp:1596:0 #24 0x01744ae0 llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/davide/work/llvm/build-rel-noassert/../lib/IR/LegacyPassManager.cpp:1699:0 #25 0x008867b0 compileModule(char**, llvm::LLVMContext&) /home/davide/work/llvm/build-rel-noassert/../tools/llc/llc.cpp:587:0 #26 0x00810c10 main /home/davide/work/llvm/build-rel-noassert/../tools/llc/llc.cpp:338:0 #27 0x7ff6eefe5731 __libc_start_main (/lib64/libc.so.6+0x20731) #28 0x0087be49 _start (./llc+0x87be49) -- 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 33080] New: AST: ItaniumMangle: CXXNameMangler::addSubstitution produce error
https://bugs.llvm.org/show_bug.cgi?id=33080
Bug ID: 33080
Summary: AST: ItaniumMangle: CXXNameMangler::addSubstitution
produce error
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: yume-wik...@live.jp
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
I was tried to compile
https://github.com/Microsoft/ChakraCore/tree/357fe4c954d776a2d40c6a9ac65931ec31585f46
However, Build was aborted.
$ ./build.sh --cxx=/usr/local/bin/clang++-4.0 --cc=/usr/local/bin/clang-4.0
--valgrind --lto-thin -j=1 -n
lto: ranlib disabled
Custom CXX /usr/local/bin/clang++-4.0
Custom CC /usr/local/bin/clang-4.0
Build path: ./out/Release
-- ./bin/ch/DbgController.js.h is up to date. skipping.
Compile Target : System Default
Generating Release makefiles
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/yumetodo/ドキュメント/ChakraCore/out/Release
[1/309] Building CXX object
lib/Runtime/ByteCode/CMakeFiles/Chakra.Runtime.ByteCode.dir/ByteCodeSerializer.cpp.o
FAILED: /usr/local/bin/clang++-4.0 -DBIT64=1 -DCAN_BUILD_WABT
-DCLANG_HAS_DISABLE_TAIL_CALLS=1 -DENABLE_VALGRIND=1 -DFEATURE_PAL
-DHAS_REAL_ICU=1 -DLINUX64 -DNO_PAL_MINMAX -DPAL_STDCPP_COMPAT
-DPLATFORM_UNIX=1 -DSTACK_ALIGN=16 -DUNICODE -D_AMD64_ -D_M_AMD64 -D_M_X64
-D_M_X64_OR_ARM64 -D_SAFECRT_USE_CPP_OVERLOADS=1 -D__LINUX__=1
-D__STDC_WANT_LIB_EXT1__=1 -I../../. -I../../lib/Common
-I../../lib/Common/PlaceHolder -I../../pal -I../../pal/inc -I../../pal/inc/rt
-I../../lib/Runtime/. -I../../lib/Runtime/../JITIDL
-I../../lib/Runtime/../Common -I../../lib/Runtime/../Backend
-I../../lib/Runtime/../Parser -I../../lib/Runtime/../WasmReader
-I../../lib/Runtime/ByteCode -I../../lib/Runtime/PlatformAgnostic
-I../../lib/Runtime/Math -Werror -Wno-ignored-attributes
-Wno-deprecated-declarations-Wno-parentheses-equality
-Wno-missing-braces-Wno-reorder-Wno-microsoft
-Wno-unused-value-Wno-int-to-void-pointer-cast
-Wno-invalid-offsetof-Wno-undefined-inline
-Wno-inconsistent-missing-override-Wno-c++14-extensions
-Wno-macro-redefined-Wno-pragmas-Wno-invalid-token-paste
-Wno-format-Wno-invalid-noreturn-Wno-null-arithmetic
-Wno-tautological-constant-out-of-range-compare
-Wno-tautological-undefined-compare-Wno-address-of-temporary
-Wno-null-conversion-Wno-return-type-Wno-switch
-Wno-implicit-function-declaration-Wno-int-to-pointer-cast
-fno-omit-frame-pointer -fdelayed-template-parsing -O3 -DNDEBUG
-fdiagnostics-color=always -msse4.2 -fasm-blocks -fms-extensions -fwrapv
-flto=thin -O3 -fPIC -std=gnu++11 -MMD -MT
lib/Runtime/ByteCode/CMakeFiles/Chakra.Runtime.ByteCode.dir/ByteCodeSerializer.cpp.o
-MF
lib/Runtime/ByteCode/CMakeFiles/Chakra.Runtime.ByteCode.dir/ByteCodeSerializer.cpp.o.d
-o
lib/Runtime/ByteCode/CMakeFiles/Chakra.Runtime.ByteCode.dir/ByteCodeSerializer.cpp.o
-c ../../lib/Runtime/ByteCode/ByteCodeSerializer.cpp
clang-4.0:
/home/yumetodo/clang_build/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:4496:
void {anonymous}::CXXNameMangler::addSubstitution(uintptr_t): Assertion
`!Substitutions.count(Ptr) && "Substitution already exists!"' failed.
#0 0x01f6c148 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x1f6c148)
#1 0x01f69b5e llvm::sys::RunSignalHandlers()
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x1f69b5e)
#2 0x01f69f62 SignalHandler(int)
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x1f69f62)
#3 0x7f57ac83d390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f57ab5b0428 gsignal
/build/glibc-9tT8Do/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f57ab5b202a abort /build/glibc-9tT8Do/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f57ab5a8bd7 __assert_fail_base
/build/glibc-9tT8Do/glibc-2.23/assert/assert.c:92:0
#7 0x7f57ab5a8c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x037e5070 (anonymous
namespace)::CXXNameMangler::addSubstitution(unsigned long)
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x37e5070)
#9 0x037ed239 (anonymous
namespace)::CXXNameMangler::mangleType(clang::QualType)
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x37ed239)
#10 0x037efb3d (anonymous
namespace)::CXXNameMangler::mangleTemplateArg(clang::TemplateArgument)
(/usr/local/llvm-4.0.0/bin/clang-4.0+0x37efb3d)
#11 0x037effe9 (anonymous
namespace)::CXXNameMangler::mangleTemplateArgs(clang::TemplateArgumentList
const&) (/usr/local/llvm-4.0.0/bin/clang-4.0+0x37effe9)
#12 0x037f01ab (anonymous
namespace)::CXXNameMangler::manglePrefix(clang::DeclContext const*, bool)
(/usr/local/llvm-4.0
[llvm-bugs] [Bug 33081] New: [ubsan] Consider not instrumenting volatile loads and stores with null checks
https://bugs.llvm.org/show_bug.cgi?id=33081 Bug ID: 33081 Summary: [ubsan] Consider not instrumenting volatile loads and stores with null checks Product: compiler-rt Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org The idea behind volatile is that accessing the memory in question has some implementation-defined semantics and side effects. Using volatile is essentially a request to get the behavior of the current implementation, whatever it may be, such as trapping to the signal handler or loading from memory that's actually mapped at zero. This came up with I added LLVM's CrashRecoveryContext tests, which intentionally dereference null. It's actually interesting to test SIGSEGV separately from testing SIGILL, which is what __builtin_trap would normally raise. -- 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 33083] New: extern "C" indentation
https://bugs.llvm.org/show_bug.cgi?id=33083
Bug ID: 33083
Summary: extern "C" indentation
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: xgal...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
There doesn't appear to be any way to affect indentation for extern "C" {}
blocks. Currently they always format to the following:
extern "C"
{
extern foo();
extern bar();
}
An option to indent inner would be great, such as:
extern "C"
{
extern foo();
extern bar();
}
--
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 33084] New: SimplifyCFG sinks instructions too aggressively
https://bugs.llvm.org/show_bug.cgi?id=33084
Bug ID: 33084
Summary: SimplifyCFG sinks instructions too aggressively
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: james.mol...@arm.com, llvm-bugs@lists.llvm.org
Testcase:
int f(int a, int b, int g(void)) {
int c;
if (g) {
g(); c = (a + 31) & -32;
} else {
c = (b + 62) & -64;
}
return c;
}
Pass this to clang -O2, and you get IR something like this:
define i32 @f(i32 %a, i32 %b, i32 ()* %g) local_unnamed_addr #0 {
entry:
%tobool = icmp eq i32 ()* %g, null
br i1 %tobool, label %if.else, label %if.then
if.then: ; preds = %entry
%call = tail call i32 %g() #1
%add = add nsw i32 %a, 31
br label %if.end
if.else: ; preds = %entry
%add1 = add nsw i32 %b, 62
br label %if.end
if.end: ; preds = %if.else, %if.then
%.sink = phi i32 [ -64, %if.else ], [ -32, %if.then ]
%add1.sink = phi i32 [ %add1, %if.else ], [ %add, %if.then ]
%and2 = and i32 %add1.sink, %.sink
ret i32 %and2
}
Sinking the "and" here might not make sense: we're generating two phi nodes to
remove one "and" instruction.
We started sinking the "and" in r280351.
I'm planning to continue looking into this, but suggestions welcome.
--
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 33085] New: wrong code with "opt -loop-rotate -mem2reg -instcombine -loop-unroll -simplifycfg -gvn -loop-reroll" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=33085
Bug ID: 33085
Summary: wrong code with "opt -loop-rotate -mem2reg
-instcombine -loop-unroll -simplifycfg -gvn
-loop-reroll" on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 5.0.0 (trunk 303312)
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/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4
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.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.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.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O3 -mllvm -disable-llvm-optzns -S -emit-llvm -o small.bc small.c
$ opt -loop-rotate -mem2reg -instcombine -loop-unroll -simplifycfg -gvn
-loop-reroll -o small-opt.bc small.bc
$ clang small-opt.bc
$ ./a.out
2
$
$ clang -O0 small.c
$ ./a.out
1
$
---
int printf (const char *, ...);
int a[1][2], b;
int main ()
{
int c;
for (; b < 1; b++)
for (c = 0; c < 2; c++)
a[b][c] = 0;
printf ("%d\n", b);
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 32649] std::__1::binomial_distribution is not thread safe
https://bugs.llvm.org/show_bug.cgi?id=32649 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Marshall Clow (home) --- This was fixed in r302168 -- 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 24313] priority queue should not copy comparators when calling push_heap and pop_heap
https://bugs.llvm.org/show_bug.cgi?id=24313 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Marshall Clow (home) --- Closing as invalid; since std::ref is a perfectly fine solution. -- 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 33086] New: clang crashes with "-mllvm -enable-newgvn": Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
https://bugs.llvm.org/show_bug.cgi?id=33086 Bug ID: 33086 Summary: clang crashes with "-mllvm -enable-newgvn": Assertion `isa(Val) && "cast() argument of incompatible type!"' failed 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 The following code crashes the current trunk version at "-O2" and "-Os" only with "-mllvm -enable-newgvn". $ clang-trunk --version clang version 5.0.0 (trunk 303238) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -mllvm -enable-newgvn -O2 abc.c abc.c:12:14: warning: relational comparison result unused [-Wunused-comparison] (g = *h) <= (c = a = c); ~^~ clang-5.0: /home/absozero/trunk/llvm/include/llvm/Support/Casting.h:247: typename cast_retty::ret_type llvm::cast(Y &) [X = llvm::GVNExpression::VariableExpression, Y = const llvm::GVNExpression::Expression]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. #0 0x01ce3324 PrintStackTraceSignalHandler(void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1ce3324) #1 0x01ce3656 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1ce3656) #2 0x7f6fea9aa330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7f6fe9527c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f6fe952b028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7f6fe9520bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x7f6fe9520ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x01be66d2 (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1be66d2) #8 0x01bd14d8 (anonymous namespace)::NewGVN::runGVN() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bd14d8) #9 0x01bcd885 NewGVNLegacyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bcd885) #10 0x0187584f llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x187584f) #11 0x026e8006 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x26e8006) #12 0x01875fa5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1875fa5) #13 0x01e6e46b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1e6e46b) #14 0x025754d7 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x25754d7) #15 0x029d8ed6 clang::ParseAST(clang::Sema&, bool, bool) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x29d8ed6) #16 0x02247eb8 clang::FrontendAction::Execute() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x2247eb8) #17 0x021fa2d1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x21fa2d1) #18 0x022cb8cd clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x22cb8cd) #19 0x0083e5dc cc1_main(llvm::ArrayRef, char const*, void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x83e5dc) #20 0x0083c4a5 main (/home/absozero/trunk/root-clang/bin/clang-5.0+0x83c4a5) #21 0x7f6fe9512f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0 #22 0x008395b9 _start (/home/absozero/trunk/root-clang/bin/clang-5.0+0x8395b9) Stack dump: 0. Program arguments: /home/absozero/trunk/root-clang/bin/clang-5.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name abc.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/absozero/trunk/root-clang/lib/clang/5.0.0 -internal-isystem /usr/local/include -internal-isystem /home/absozero/trunk/root-clang/lib/clang/5.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /home/absozero/projects/reduction/crash -ferror-limit 19 -fmessage-length 172 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -mllvm -en
