[llvm-bugs] [Bug 26232] [AVX-512] llc fails with with setcce

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26232

igorb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||igor.bre...@intel.com
 Resolution|--- |FIXED

--- Comment #1 from igorb  ---
fixed in r259342

http://reviews.llvm.org/D16752

-- 
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 26338] [AVX512]: 3.8 and trunk llc fails on gather.qps and scatter.qps

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26338

igorb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||igor.bre...@intel.com
 Resolution|--- |FIXED

--- Comment #1 from igorb  ---
fixed in r259346

http://reviews.llvm.org/D16755

-- 
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 25879] Incorrect schedule is generated

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25879

Tobias Grosser  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tob...@grosser.es
 Resolution|--- |FIXED

--- Comment #2 from Tobias Grosser  ---
https://llvm.org/svn/llvm-project/polly/trunk@259354

-- 
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 26409] New: __attribute__ ((interrupt)) uses xmm31 with -march=nehalem

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26409

Bug ID: 26409
   Summary: __attribute__ ((interrupt)) uses xmm31 with
-march=nehalem
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

hjl@gnu-6 interrupt-8]$ cat x.i
extern void subroutine1(void);

__attribute__ ((interrupt))
void ih(void * frame)
{
  subroutine1();
}
[hjl@gnu-6 interrupt-8]$ make
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -S -o x.s x.i
grep xmm x.s
movaps%xmm31, 368(%rsp)   # 16-byte Spill
movaps%xmm30, 352(%rsp)   # 16-byte Spill
movaps%xmm29, 336(%rsp)   # 16-byte Spill
movaps%xmm28, 320(%rsp)   # 16-byte Spill
movaps%xmm27, 304(%rsp)   # 16-byte Spill
movaps%xmm26, 288(%rsp)   # 16-byte Spill
movaps%xmm25, 272(%rsp)   # 16-byte Spill
movaps%xmm24, 256(%rsp)   # 16-byte Spill
movaps%xmm23, 240(%rsp)   # 16-byte Spill
movaps%xmm22, 224(%rsp)   # 16-byte Spill
movaps%xmm21, 208(%rsp)   # 16-byte Spill
movaps%xmm20, 192(%rsp)   # 16-byte Spill
movaps%xmm19, 176(%rsp)   # 16-byte Spill
movaps%xmm18, 160(%rsp)   # 16-byte Spill
movaps%xmm17, 144(%rsp)   # 16-byte Spill
movaps%xmm16, 128(%rsp)   # 16-byte Spill
movaps%xmm15, 112(%rsp)   # 16-byte Spill
movaps%xmm14, 96(%rsp)# 16-byte Spill
movaps%xmm13, 80(%rsp)# 16-byte Spill
movaps%xmm12, 64(%rsp)# 16-byte Spill
movaps%xmm11, 48(%rsp)# 16-byte Spill
movaps%xmm10, 32(%rsp)# 16-byte Spill
movaps%xmm9, 16(%rsp) # 16-byte Spill
movaps%xmm8, (%rsp)   # 16-byte Spill
movaps%xmm7, -16(%rsp)# 16-byte Spill
movaps%xmm6, -32(%rsp)# 16-byte Spill
movaps%xmm5, -48(%rsp)# 16-byte Spill
movaps%xmm4, -64(%rsp)# 16-byte Spill
movaps%xmm3, -80(%rsp)# 16-byte Spill
movaps%xmm2, -96(%rsp)# 16-byte Spill
movaps%xmm1, -112(%rsp)   # 16-byte Spill
movaps%xmm0, -128(%rsp)   # 16-byte Spill
.cfi_offset %xmm0, -608
.cfi_offset %xmm1, -592
.cfi_offset %xmm2, -576
.cfi_offset %xmm3, -560
.cfi_offset %xmm4, -544
.cfi_offset %xmm5, -528
.cfi_offset %xmm6, -512
.cfi_offset %xmm7, -496
.cfi_offset %xmm8, -480
.cfi_offset %xmm9, -464
.cfi_offset %xmm10, -448
.cfi_offset %xmm11, -432
.cfi_offset %xmm12, -416
.cfi_offset %xmm13, -400
.cfi_offset %xmm14, -384
.cfi_offset %xmm15, -368
.cfi_offset %xmm16, -352
.cfi_offset %xmm17, -336
.cfi_offset %xmm18, -320
.cfi_offset %xmm19, -304
.cfi_offset %xmm20, -288
.cfi_offset %xmm21, -272
.cfi_offset %xmm22, -256
.cfi_offset %xmm23, -240
.cfi_offset %xmm24, -224
.cfi_offset %xmm25, -208
.cfi_offset %xmm26, -192
.cfi_offset %xmm27, -176
.cfi_offset %xmm28, -160
.cfi_offset %xmm29, -144
.cfi_offset %xmm30, -128
.cfi_offset %xmm31, -112
movaps-128(%rsp), %xmm0   # 16-byte Reload
movaps-112(%rsp), %xmm1   # 16-byte Reload
movaps-96(%rsp), %xmm2# 16-byte Reload
movaps-80(%rsp), %xmm3# 16-byte Reload
movaps-64(%rsp), %xmm4# 16-byte Reload
movaps-48(%rsp), %xmm5# 16-byte Reload
movaps-32(%rsp), %xmm6# 16-byte Reload
movaps-16(%rsp), %xmm7# 16-byte Reload
movaps(%rsp), %xmm8   # 16-byte Reload
movaps16(%rsp), %xmm9 # 16-byte Reload
movaps32(%rsp), %xmm10# 16-byte Reload
movaps48(%rsp), %xmm11# 16-byte Reload
movaps64(%rsp), %xmm12# 16-byte Reload
movaps80(%rsp), %xmm13# 16-byte Reload
movaps96(%rsp), %xmm14# 16-byte Reload
movaps112(%rsp), %xmm15   # 16-byte Reload
movaps128(%rsp), %xmm16   # 16-byte Reload
movaps144(%rsp), %xmm17   # 16-byte Reload
movaps160(%rsp), %xmm18   # 16-byte Reload
movaps176(%rsp), %xmm19   # 16-byte Reload
movaps192(%rsp), %xmm20   # 16-byte Reload
movaps208(%rsp), %xmm21   # 16-byte Reload
movaps224(%rsp), %xmm22   # 16-byte Reload
movaps240(%rsp), %xmm23   # 16-byte Reload
movaps256(%rsp), %xmm24   # 16-byte Reload
movaps272(%rsp), %xmm25   # 16-byte Reload
movaps288(%rsp), %xmm26   # 16-byte Reload
movaps

[llvm-bugs] [Bug 26410] New: __attribute__((interrupt)) compiles never finishes

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26410

Bug ID: 26410
   Summary: __attribute__((interrupt)) compiles never finishes
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

[hjl@gnu-6 interrupt-8]$ cat y.i 
typedef unsigned int uword_t __attribute__ ((mode (__word__)));

extern long double y, x;

void
__attribute__((interrupt))
fn1 (void *frame, uword_t error)
{
  x = 0;
}

void
__attribute__((interrupt))
fn2 (void *frame)
{
  x = y;
}
[hjl@gnu-6 interrupt-8]$ make y.s
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -S -o y.s y.i

-- 
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 26411] New: __attribute__((interrupt)) trashes MMX registers

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26411

Bug ID: 26411
   Summary: __attribute__((interrupt)) trashes MMX registers
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

[hjl@gnu-6 interrupt-8]$ cat z.i
typedef short __v4hi __attribute__ ((__vector_size__ (8)));
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));

extern __m64 y, x;

void
__attribute__((interrupt))
fn1 (void *frame)
{
  x = (__m64) __builtin_ia32_packsswb ((__v4hi) x, (__v4hi) y);
}
[hjl@gnu-6 interrupt-8]$ make z.s
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -S -o z.s z.i
[hjl@gnu-6 interrupt-8]$ cat z.s
.text
.file"z.i"
.globlfn1
.p2align4, 0x90
.typefn1,@function
fn1:# @fn1
.cfi_startproc
# BB#0:
movqx(%rip), %mm0
packsswby(%rip), %mm0
movq%mm0, x(%rip)
iretq
.Lfunc_end0:
.sizefn1, .Lfunc_end0-fn1
.cfi_endproc


.ident"clang version 3.9.0 (http://llvm.org/git/clang.git
1f64ddbc4c5d1036b68ec896765a7535537ded85) (http://llvm.org/git/llvm.git
43b517fe4e0a181b1cf20f36fd9eb92f7b32946c)"
.section".note.GNU-stack","",@progbits
[hjl@gnu-6 interrupt-8]$ 

Interrupt handler must preserve MMX and X87 states.  It shouldn't be
allowed to use MMX nor x87 registers.

-- 
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 26412] New: vzeroupper is generated in interrupt handler

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26412

Bug ID: 26412
   Summary: vzeroupper is generated in interrupt handler
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

[hjl@gnu-6 interrupt-8]$ cat s.i
extern void foo (void *) __attribute__ ((interrupt));
extern void bar (void);

void foo (void *frame)
{
  bar ();
}
[hjl@gnu-6 interrupt-8]$ make s.s
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -mavx -S -o s.s s.i
[hjl@gnu-6 interrupt-8]$ grep vzero s.s
vzeroupper
[hjl@gnu-6 interrupt-8]$

-- 
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 26413] New: movaps is generated in interrupt handler

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26413

Bug ID: 26413
   Summary: movaps is generated in interrupt handler
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

[hjl@gnu-6 interrupt-8]$ cat x.i 
extern void subroutine1(void);

__attribute__ ((interrupt))
void ih(void * frame)
{
  subroutine1();
}
[hjl@gnu-6 interrupt-8]$ make x.s
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -S -o x.s x.i
[hjl@gnu-6 interrupt-8]$ cat x.s
.text
.file"x.i"
.globlih
.p2align4, 0x90
.typeih,@function
ih: # @ih
.cfi_startproc
# BB#0:
pushq%rsp
.Ltmp0:
.cfi_def_cfa_offset 16
pushq%rax
.Ltmp1:
.cfi_def_cfa_offset 24
pushq%r11
.Ltmp2:
.cfi_def_cfa_offset 32
pushq%r10
.Ltmp3:
.cfi_def_cfa_offset 40
pushq%r9
.Ltmp4:
.cfi_def_cfa_offset 48
pushq%r8
.Ltmp5:
.cfi_def_cfa_offset 56
pushq%rdi
.Ltmp6:
.cfi_def_cfa_offset 64
pushq%rsi
.Ltmp7:
.cfi_def_cfa_offset 72
pushq%rdx
.Ltmp8:
.cfi_def_cfa_offset 80
pushq%rcx
.Ltmp9:
.cfi_def_cfa_offset 88
subq$392, %rsp  # imm = 0x188
movaps%xmm31, 368(%rsp)   # 16-byte Spill
movaps%xmm30, 352(%rsp)   # 16-byte Spill
movaps%xmm29, 336(%rsp)   # 16-byte Spill
movaps%xmm28, 320(%rsp)   # 16-byte Spill
movaps%xmm27, 304(%rsp)   # 16-byte Spill
movaps%xmm26, 288(%rsp)   # 16-byte Spill
movaps%xmm25, 272(%rsp)   # 16-byte Spill
movaps%xmm24, 256(%rsp)   # 16-byte Spill
movaps%xmm23, 240(%rsp)   # 16-byte Spill
movaps%xmm22, 224(%rsp)   # 16-byte Spill
movaps%xmm21, 208(%rsp)   # 16-byte Spill
movaps%xmm20, 192(%rsp)   # 16-byte Spill
movaps%xmm19, 176(%rsp)   # 16-byte Spill
movaps%xmm18, 160(%rsp)   # 16-byte Spill
movaps%xmm17, 144(%rsp)   # 16-byte Spill
movaps%xmm16, 128(%rsp)   # 16-byte Spill
movaps%xmm15, 112(%rsp)   # 16-byte Spill
movaps%xmm14, 96(%rsp)# 16-byte Spill
movaps%xmm13, 80(%rsp)# 16-byte Spill
movaps%xmm12, 64(%rsp)# 16-byte Spill
movaps%xmm11, 48(%rsp)# 16-byte Spill
movaps%xmm10, 32(%rsp)# 16-byte Spill
movaps%xmm9, 16(%rsp) # 16-byte Spill
movaps%xmm8, (%rsp)   # 16-byte Spill
movaps%xmm7, -16(%rsp)# 16-byte Spill
movaps%xmm6, -32(%rsp)# 16-byte Spill
movaps%xmm5, -48(%rsp)# 16-byte Spill
movaps%xmm4, -64(%rsp)# 16-byte Spill
movaps%xmm3, -80(%rsp)# 16-byte Spill
movaps%xmm2, -96(%rsp)# 16-byte Spill
movaps%xmm1, -112(%rsp)   # 16-byte Spill
movaps%xmm0, -128(%rsp)   # 16-byte Spill
.Ltmp10:
.cfi_def_cfa_offset 480
.Ltmp11:
.cfi_offset %rcx, -88
.Ltmp12:
.cfi_offset %rdx, -80
.Ltmp13:
.cfi_offset %rsi, -72
.Ltmp14:
.cfi_offset %rdi, -64
.Ltmp15:
.cfi_offset %r8, -56
.Ltmp16:
.cfi_offset %r9, -48
.Ltmp17:
.cfi_offset %r10, -40
.Ltmp18:
.cfi_offset %r11, -32
.Ltmp19:
.cfi_offset %xmm0, -608
.Ltmp20:
.cfi_offset %xmm1, -592
.Ltmp21:
.cfi_offset %xmm2, -576
.Ltmp22:
.cfi_offset %xmm3, -560
.Ltmp23:
.cfi_offset %xmm4, -544
.Ltmp24:
.cfi_offset %xmm5, -528
.Ltmp25:
.cfi_offset %xmm6, -512
.Ltmp26:
.cfi_offset %xmm7, -496
.Ltmp27:
.cfi_offset %xmm8, -480
.Ltmp28:
.cfi_offset %xmm9, -464
.Ltmp29:
.cfi_offset %xmm10, -448
.Ltmp30:
.cfi_offset %xmm11, -432
.Ltmp31:
.cfi_offset %xmm12, -416
.Ltmp32:
.cfi_offset %xmm13, -400
.Ltmp33:
.cfi_offset %xmm14, -384
.Ltmp34:
.cfi_offset %xmm15, -368
.Ltmp35:
.cfi_offset %rax, -24
.Ltmp36:
.cfi_offset %rsp, -16
.Ltmp37:
.cfi_offset %xmm16, -352
.Ltmp38:
.cfi_offset %xmm17, -336
.Ltmp39:
.cfi_offset %xmm18, -320
.Ltmp40:
.cfi_offset %xmm19, -304
.Ltmp41:
.cfi_offset %xmm20, -288
.Ltmp42:
.cfi_offset %xmm21, -272
.Ltmp43:
.cfi_offset %xmm22, -256
.Ltmp44:
.cfi_offset %xmm23, -240
.Ltmp45:
.cfi_offset %xmm24, -224
.Ltmp46:
.cfi_offset %xmm25, -208
.Ltmp47:
.cfi_offset %xmm26, -192
.Ltmp48:
.cfi_offset %xmm27, -176
.Ltmp49:
.cfi_offset %xmm28, -160
.Ltmp50:
.cfi_offset %xmm29, -144
.Ltmp51:
.cfi_offset %xmm30, -128
.Ltmp52:
.cfi_offset %xmm31, -112
movaps-128(%rsp), %xmm0   # 16-byte Reload
movaps-112(%rsp), %

[llvm-bugs] [Bug 26414] New: Tail call is generated in interrupt handler

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26414

Bug ID: 26414
   Summary: Tail call is generated in interrupt handler
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: hjl.to...@gmail.com
CC: kevin.b.sm...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified

[hjl@gnu-6 interrupt-8]$ cat x.i 
extern void subroutine1(void);

__attribute__ ((interrupt))
void ih(void * frame)
{
  subroutine1();
}
[hjl@gnu-6 interrupt-8]$ make x.s
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -O2
-Wall -march=nehalem -S -o x.s x.i
[hjl@gnu-6 interrupt-8]$ cat x.s
.text
.file"x.i"
.globlih
.p2align4, 0x90
.typeih,@function
ih: # @ih
.cfi_startproc
# BB#0:
pushq%rsp
.Ltmp0:
.cfi_def_cfa_offset 16
pushq%rax
.Ltmp1:
.cfi_def_cfa_offset 24
pushq%r11
.Ltmp2:
.cfi_def_cfa_offset 32
pushq%r10
.Ltmp3:
.cfi_def_cfa_offset 40
pushq%r9
.Ltmp4:
.cfi_def_cfa_offset 48
pushq%r8
.Ltmp5:
.cfi_def_cfa_offset 56
pushq%rdi
.Ltmp6:
.cfi_def_cfa_offset 64
pushq%rsi
.Ltmp7:
.cfi_def_cfa_offset 72
pushq%rdx
.Ltmp8:
.cfi_def_cfa_offset 80
pushq%rcx
.Ltmp9:
.cfi_def_cfa_offset 88
subq$392, %rsp  # imm = 0x188
movaps%xmm31, 368(%rsp)   # 16-byte Spill
movaps%xmm30, 352(%rsp)   # 16-byte Spill
movaps%xmm29, 336(%rsp)   # 16-byte Spill
movaps%xmm28, 320(%rsp)   # 16-byte Spill
movaps%xmm27, 304(%rsp)   # 16-byte Spill
movaps%xmm26, 288(%rsp)   # 16-byte Spill
movaps%xmm25, 272(%rsp)   # 16-byte Spill
movaps%xmm24, 256(%rsp)   # 16-byte Spill
movaps%xmm23, 240(%rsp)   # 16-byte Spill
movaps%xmm22, 224(%rsp)   # 16-byte Spill
movaps%xmm21, 208(%rsp)   # 16-byte Spill
movaps%xmm20, 192(%rsp)   # 16-byte Spill
movaps%xmm19, 176(%rsp)   # 16-byte Spill
movaps%xmm18, 160(%rsp)   # 16-byte Spill
movaps%xmm17, 144(%rsp)   # 16-byte Spill
movaps%xmm16, 128(%rsp)   # 16-byte Spill
movaps%xmm15, 112(%rsp)   # 16-byte Spill
movaps%xmm14, 96(%rsp)# 16-byte Spill
movaps%xmm13, 80(%rsp)# 16-byte Spill
movaps%xmm12, 64(%rsp)# 16-byte Spill
movaps%xmm11, 48(%rsp)# 16-byte Spill
movaps%xmm10, 32(%rsp)# 16-byte Spill
movaps%xmm9, 16(%rsp) # 16-byte Spill
movaps%xmm8, (%rsp)   # 16-byte Spill
movaps%xmm7, -16(%rsp)# 16-byte Spill
movaps%xmm6, -32(%rsp)# 16-byte Spill
movaps%xmm5, -48(%rsp)# 16-byte Spill
movaps%xmm4, -64(%rsp)# 16-byte Spill
movaps%xmm3, -80(%rsp)# 16-byte Spill
movaps%xmm2, -96(%rsp)# 16-byte Spill
movaps%xmm1, -112(%rsp)   # 16-byte Spill
movaps%xmm0, -128(%rsp)   # 16-byte Spill
.Ltmp10:
.cfi_def_cfa_offset 480
.Ltmp11:
.cfi_offset %rcx, -88
.Ltmp12:
.cfi_offset %rdx, -80
.Ltmp13:
.cfi_offset %rsi, -72
.Ltmp14:
.cfi_offset %rdi, -64
.Ltmp15:
.cfi_offset %r8, -56
.Ltmp16:
.cfi_offset %r9, -48
.Ltmp17:
.cfi_offset %r10, -40
.Ltmp18:
.cfi_offset %r11, -32
.Ltmp19:
.cfi_offset %xmm0, -608
.Ltmp20:
.cfi_offset %xmm1, -592
.Ltmp21:
.cfi_offset %xmm2, -576
.Ltmp22:
.cfi_offset %xmm3, -560
.Ltmp23:
.cfi_offset %xmm4, -544
.Ltmp24:
.cfi_offset %xmm5, -528
.Ltmp25:
.cfi_offset %xmm6, -512
.Ltmp26:
.cfi_offset %xmm7, -496
.Ltmp27:
.cfi_offset %xmm8, -480
.Ltmp28:
.cfi_offset %xmm9, -464
.Ltmp29:
.cfi_offset %xmm10, -448
.Ltmp30:
.cfi_offset %xmm11, -432
.Ltmp31:
.cfi_offset %xmm12, -416
.Ltmp32:
.cfi_offset %xmm13, -400
.Ltmp33:
.cfi_offset %xmm14, -384
.Ltmp34:
.cfi_offset %xmm15, -368
.Ltmp35:
.cfi_offset %rax, -24
.Ltmp36:
.cfi_offset %rsp, -16
.Ltmp37:
.cfi_offset %xmm16, -352
.Ltmp38:
.cfi_offset %xmm17, -336
.Ltmp39:
.cfi_offset %xmm18, -320
.Ltmp40:
.cfi_offset %xmm19, -304
.Ltmp41:
.cfi_offset %xmm20, -288
.Ltmp42:
.cfi_offset %xmm21, -272
.Ltmp43:
.cfi_offset %xmm22, -256
.Ltmp44:
.cfi_offset %xmm23, -240
.Ltmp45:
.cfi_offset %xmm24, -224
.Ltmp46:
.cfi_offset %xmm25, -208
.Ltmp47:
.cfi_offset %xmm26, -192
.Ltmp48:
.cfi_offset %xmm27, -176
.Ltmp49:
.cfi_offset %xmm28, -160
.Ltmp50:
.cfi_offset %xmm29, -144
.Ltmp51:
.cfi_offset %xmm30, -128
.Ltmp52:
.cfi_offset %xmm31, -112
movaps-128(%rsp), %xmm0   # 16-byte Reload
movaps-112(%rsp), %xmm1

[llvm-bugs] [Bug 25520] [LIR] Add support for structs and hand unrolled loops

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25520

Haicheng Wu  changed:

   What|Removed |Added

 Status|ASSIGNED|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 26415] New: UBSan-Standalone-x86_64 :: TestCases/Misc/vla.c has been failing on clang-x64-ninja-win7 for one week (1) after cross-DSO CFI diagnostics landed

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26415

Bug ID: 26415
   Summary: UBSan-Standalone-x86_64 :: TestCases/Misc/vla.c has
been failing on clang-x64-ninja-win7 for one week (1)
after cross-DSO CFI diagnostics landed
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: compiler-rt
  Assignee: unassignedb...@nondot.org
  Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7

 TEST 'UBSan-Standalone-x86_64 :: TestCases/Misc/vla.c'
FAILED 
Script:
--
D:/buildslave/clang-x64-ninja-win7/stage2/./bin/clang.exe  -fsanitize=vla-bound
D:\buildslave\clang-x64-ninja-win7\llvm\projects\compiler-rt\test\ubsan\TestCases\Misc\vla.c
-O3 -o
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp
2>&1 | FileCheck
D:\buildslave\clang-x64-ninja-win7\llvm\projects\compiler-rt\test\ubsan\TestCases\Misc\vla.c
--check-prefix=CHECK-MINUS-ONE
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp
a 2>&1 | FileCheck
D:\buildslave\clang-x64-ninja-win7\llvm\projects\compiler-rt\test\ubsan\TestCases\Misc\vla.c
--check-prefix=CHECK-ZERO
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp
a b
--
Exit Code: 1120

Command Output (stdout):
--
Command 0: "D:/buildslave/clang-x64-ninja-win7/stage2/./bin/clang.exe"
"-fsanitize=vla-bound"
"D:\buildslave\clang-x64-ninja-win7\llvm\projects\compiler-rt\test\ubsan\TestCases\Misc\vla.c"
"-O3" "-o"
"D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp"
Command 0 Result: 1120
Command 0 Output:
   Creating library
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.lib
and object
D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.exp

clang_rt.ubsan_standalone-x86_64.lib(ubsan_handlers.cc.obj) : error LNK2019:
unresolved external symbol "void __cdecl __ubsan::HandleCFIBadType(struct
__ubsan::CFICheckFailData *,unsigned __int64,struct __ubsan::ReportOptions)"
(?HandleCFIBadType@__ubsan@@YAXPEAUCFICheckFailData@1@_KUReportOptions@1@@Z)
referenced in function __ubsan_handle_cfi_check_fail

D:\buildslave\clang-x64-ninja-win7\stage2\projects\compiler-rt\test\ubsan\Standalone-x86_64\TestCases\Misc\Output\vla.c.tmp
: fatal error LNK1120: 1 unresolved externals



Command 0 Stderr:
clang.exe: error: linker command failed with exit code 1120 (use -v to see
invocation)

-- 
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 26395] Analyzer says undefined behavior in uniform_int_distribution

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26395

Marshall Clow (home)  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Marshall Clow (home)  ---
This has been fixed in trunk as part of fixing
https://llvm.org/bugs/show_bug.cgi?id=24267.

Fixed in revision 243674, committed last July, so it should have been part of

-- 
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 26416] New: fatal error: error in backend: Broken function found, compilation aborted!

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26416

Bug ID: 26416
   Summary: fatal error: error in backend: Broken function found,
compilation aborted!
   Product: clang
   Version: 3.6
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: nezzari.ine...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Error when trying to clone binary operations using the following pass:

if (auto *op = dyn_cast(&*I)) { auto temp = op->clone();}

favorite


Error when trying to clone binary operations using the following pass:

if (auto *op = dyn_cast(&*I)) { auto temp = op->clone();}

this gives the following error: fatal error: error in backend: Broken function
found, compilation aborted! clang-3.6: error: clang frontend command failed
with exit code 70 (use -v to see invocation) clang version 3.6.2
(tags/RELEASE_362/final) Target: x86_64-unknown-linux-gnu Thread model: posix
clang-3.6: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script. clang-3.6: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and
associated run script(s) are located at: clang-3.6: note: diagnostic msg:
/tmp/add1-260d76.c clang-3.6: note: diagnostic msg: /tmp/add1-260d76.sh
clang-3.6: note: diagnostic msg:

-- 
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 26417] New: Add AVX-512 support in X86TargetLowering::emitFMA3Instr

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26417

Bug ID: 26417
   Summary: Add AVX-512 support in
X86TargetLowering::emitFMA3Instr
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: hfin...@anl.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15788
  --> https://llvm.org/bugs/attachment.cgi?id=15788&action=edit
Kernel where this might matter

In llvm/lib/Target/X86/X86ISelLowering.cpp we have:

// Replace 213-type (isel default) FMA3 instructions with 231-type for
// accumulator loops. Writing back to the accumulator allows the coalescer
// to remove extra copies in the loop.
// FIXME: Do this on AVX512.  We don't support 231 variants yet (PR23937).
MachineBasicBlock *
X86TargetLowering::emitFMA3Instr(MachineInstr *MI,
 MachineBasicBlock *MBB) const {
...

But PR23937 has now been fixed, and we should add AVX-512 support here.

I've attached a small test case (C with intrinsics) where I suspect this might
matter.

$ clang -S -o - -march=knl -O3 ~/tmp/avx512mm.c

...

.LBB0_3:# %.preheader10
#   Parent Loop BB0_1 Depth=1
# Parent Loop BB0_2 Depth=2
# =>This Inner Loop Header: Depth=3
vmovaps%zmm1, %zmm8
vmovaps%zmm2, %zmm9
vmovaps%zmm3, %zmm10
vmovaps%zmm4, %zmm11
vmovaps%zmm6, %zmm12
vmovaps%zmm7, %zmm13
vmovaps%zmm0, %zmm14
vmovaps%zmm5, %zmm1
vmovapd(%rdx), %zmm0
vmovaps%zmm0, %zmm5
vfmadd231pd-7168(%r14){1to8}, %zmm1, %zmm5
vmovaps%zmm0, %zmm1
vfmadd231pd-6144(%r14){1to8}, %zmm8, %zmm1
vmovaps%zmm0, %zmm2
vfmadd231pd-5120(%r14){1to8}, %zmm9, %zmm2
vmovaps%zmm0, %zmm3
vfmadd231pd-4096(%r14){1to8}, %zmm10, %zmm3
vmovaps%zmm0, %zmm4
vfmadd231pd-3072(%r14){1to8}, %zmm11, %zmm4
vmovaps%zmm0, %zmm6
vfmadd231pd-2048(%r14){1to8}, %zmm12, %zmm6
vmovaps%zmm0, %zmm7
vfmadd231pd-1024(%r14){1to8}, %zmm13, %zmm7
vfmadd231pd(%r14){1to8}, %zmm14, %zmm0
addq$8, %r14
addq$1024, %rdx # imm = 0x400
decq%r10
jne.LBB0_3

...

and I this should select a different FMA form to avoid the excess moves.

-- 
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 26418] New: Instruction scheduling model for the KNL

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26418

Bug ID: 26418
   Summary: Instruction scheduling model for the KNL
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: hfin...@anl.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

We need to have a real instruction scheduling model for the KNL. Aside from
anything else, it seems reasonable to switch the default to be more like
Silvermont than like Haswell, plus there is a significant amount of information
here (under the "MICROARCHITECTURE" heading):

 
https://software.intel.com/en-us/articles/what-disclosures-has-intel-made-about-knights-landing

plus from Avinash's HotChips presentation:

 
http://www.hotchips.org/wp-content/uploads/hc_archives/hc27/HC27.25-Tuesday-Epub/HC27.25.70-Processors-Epub/HC27.25.710-Knights-Landing-Sodani-Intel.pdf

-- 
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 26407] Wrong constant folding

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26407

David Majnemer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Backend: C  |Scalar Optimizations
 Resolution|--- |FIXED
   Assignee|unassignedb...@nondot.org   |david.majne...@gmail.com

--- Comment #4 from David Majnemer  ---
Fixed in r259375.

-- 
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 26419] New: -function-summary produces non deterministic output

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26419

Bug ID: 26419
   Summary: -function-summary produces non deterministic output
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: rafael.espind...@gmail.com
CC: llvm-bugs@lists.llvm.org, mehdi.am...@apple.com,
tejohn...@google.com
Classification: Unclassified

llvm-as -function-summary test.ll && md5sum test.bc
2940afcf52e6def4636ea8552d46ab89  test.bc
llvm-as -function-summary test.ll && md5sum test.bc
0d6fbd701478ad755060965d8562965c  test.bc

test.ll is just

define void @foo() {
ret void
}

define void @bar() {
ret void
}

-- 
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 21984] Add Clang warning for trailing returns;

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=21984

Eugene Zelenko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Eugene Zelenko  ---
Fixed in r259362.

-- 
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 26420] New: Compilation of attached code with -O2 takes infinitely long, -O1 works.

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26420

Bug ID: 26420
   Summary: Compilation of attached code with -O2 takes infinitely
long, -O1 works.
   Product: clang
   Version: 3.7
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: andreas.nei...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15789
  --> https://llvm.org/bugs/attachment.cgi?id=15789&action=edit
Auto-generated clang script

The attached auto-generated code takes infinitely long with optimization level
2 (-O2). When switching to -O1, it works fine. 

Using clang on ArchLinux:

clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Maybe that's already fixed in upstream, and somebody could quickly test that
with the attached scripts/source file.

-- 
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 26415] UBSan-Standalone-x86_64 :: TestCases/Misc/vla.c has been failing on clang-x64-ninja-win7 for one week (1) after cross-DSO CFI diagnostics landed

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26415

Reid Kleckner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r...@google.com
 Resolution|--- |FIXED

--- Comment #2 from Reid Kleckner  ---
Should be fixed with r259388

-- 
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 26364] Segmentation fault at -Os and above on x86_64-linux-gnu in 32-bit and 64-bit modes

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26364

Matthew Simpson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Matthew Simpson  ---
Patch reapplied with fix in r259357. Regression test added in r259385. Thanks
Chengnian and David.

-- 
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 26084] [AArch64] Missed CCMP opportunity

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26084

Balaram Makam  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Balaram Makam  ---
fixed in r259387.

-- 
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 25717] 'IO failure on output stream' with -E on Windows

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25717

Yunzhong Gao  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassignedclangbugs@nondot. |yunzhong_...@playstation.so
   |org |ny.com

--- Comment #6 from Yunzhong Gao  ---
The fix is committed in r256892.
The test is commited in r258898 and r258902.
The test is enabled on buildbot in r259248.

Resolving the bug.

-- 
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 26421] New: CommandObjectRegister should set status eReturnStatusSuccessFinishResult

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26421

Bug ID: 26421
   Summary: CommandObjectRegister should set status
eReturnStatusSuccessFinishResult
   Product: lldb
   Version: 3.8
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: git...@newplanetsoftware.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15791
  --> https://llvm.org/bugs/attachment.cgi?id=15791&action=edit
Suggested patch

CommandObjectRegister::DoExecute() never sets the result status to
eReturnStatusSuccessFinishResult.  It should set this if DumpRegister() returns
true.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 26419] -function-summary produces non deterministic output

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26419

Rafael Ávila de Espíndola  changed:

   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 26422] New: lua/generate_inputs.sh problem with parallel make

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26422

Bug ID: 26422
   Summary: lua/generate_inputs.sh problem with parallel make
   Product: Test Suite
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Programs Tests
  Assignee: unassignedb...@nondot.org
  Reporter: hfin...@anl.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When using cmake to generate makefiles, running:

  make -j test-suite

often fails with:

/bin/sh: /home/xxx/public/build/x86_64/llvm-stage1/test-suite
bins/MultiSource/Applications/lua/generate_inputs.sh: No such file or directory
make[6]: *** [MultiSource/Applications/lua/generate_inputs.sh] Error 127
make[5]: *** [MultiSource/Applications/lua/CMakeFiles/lua_input.dir/all] Error
2
make[5]: *** Waiting for unfinished jobs

I've observed no problems with a serial run.

-- 
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 26423] New: Segfaulting on C++ ADL

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26423

Bug ID: 26423
   Summary: Segfaulting on C++ ADL
   Product: clang
   Version: 3.7
  Hardware: Macintosh
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: lotham2...@yahoo.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I was trying to get my code to get along with ADL. clang seemed a little
confused, suggesting that I put the file it couldn't find into REDACTED::util,
when the parameter in question is in REDACTED::test::mock and the function
using ADL was in REDACTED::sidx::cnc. Following its advice and putting the
function in REDACTED::util caused this segfault. My workaround was to put the
function in REDACTED::sidx::cnc and then reorder the includes to be sure that
the function declaration was always included before its ADL reference in
CacheUpdateJob.h

Here is the error that Clang gave me:



#0 0x159672d llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/bin/clang-3.7+0x159672d)
#1 0x1595621 SignalHandler(int) (/usr/local/bin/clang-3.7+0x1595621)
#2 0x7f584bd7c790 __restore_rt (/lib64/libpthread.so.0+0xf790)
#3 0x1756d72 UnwrapTypeForDebugInfo(clang::QualType, clang::ASTContext const&)
[clone .constprop.764] (/usr/local/bin/clang-3.7+0x1756d72)
#4 0x175df19 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType,
llvm::DIFile*) (/usr/local/bin/clang-3.7+0x175df19)
#5 0x175f1c2 clang::CodeGen::CGDebugInfo::CreateType(clang::FunctionType
const*, llvm::DIFile*) (/usr/local/bin/clang-3.7+0x175f1c2)
#6 0x175df46 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType,
llvm::DIFile*) (/usr/local/bin/clang-3.7+0x175df46)
#7 0x17647bb clang::CodeGen::CGDebugInfo::getOrCreateFunctionType(clang::Decl
const*, clang::QualType, llvm::DIFile*) (/usr/local/bin/clang-3.7+0x17647bb)
#8 0x1764dbd
clang::CodeGen::CGDebugInfo::getFunctionForwardDeclaration(clang::FunctionDecl
const*) (/usr/local/bin/clang-3.7+0x1764dbd)
#9 0x17653c0
clang::CodeGen::CGDebugInfo::getDeclarationOrDefinition(clang::Decl const*)
(/usr/local/bin/clang-3.7+0x17653c0)
#10 0x17654ba clang::CodeGen::CGDebugInfo::EmitUsingDecl(clang::UsingDecl
const&) (/usr/local/bin/clang-3.7+0x17654ba)
#11 0x181cf97 clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt
const&) (/usr/local/bin/clang-3.7+0x181cf97)
#12 0x1826627 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt
const*) (/usr/local/bin/clang-3.7+0x1826627)
#13 0x1822980 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*)
(/usr/local/bin/clang-3.7+0x1822980)
#14 0x1822dcf
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/usr/local/bin/clang-3.7+0x1822dcf)
#15 0x18410a2
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) (/usr/local/bin/clang-3.7+0x18410a2)
#16 0x18475a3 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
(/usr/local/bin/clang-3.7+0x18475a3)
#17 0x16ab781
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/bin/clang-3.7+0x16ab781)
#18 0x16b84c5
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/bin/clang-3.7+0x16b84c5)
#19 0x16b861e clang::CodeGen::CodeGenModule::EmitDeferred()
(/usr/local/bin/clang-3.7+0x16b861e)
#20 0x16b863a clang::CodeGen::CodeGenModule::EmitDeferred()
(/usr/local/bin/clang-3.7+0x16b863a)
#21 0x16b863a clang::CodeGen::CodeGenModule::EmitDeferred()
(/usr/local/bin/clang-3.7+0x16b863a)
#22 0x16b86f9 clang::CodeGen::CodeGenModule::Release()
(/usr/local/bin/clang-3.7+0x16b86f9)
#23 0x1b7233d clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/usr/local/bin/clang-3.7+0x1b7233d)
#24 0x1e20082 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/bin/clang-3.7+0x1e20082)
#25 0x19198d6 clang::FrontendAction::Execute()
(/usr/local/bin/clang-3.7+0x19198d6)
#26 0x18f20e9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/bin/clang-3.7+0x18f20e9)
#27 0x19925fb clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/bin/clang-3.7+0x19925fb)
#28 0x6e8200 cc1_main(llvm::ArrayRef, char const*, void*)
(/usr/local/bin/clang-3.7+0x6e8200)
#29 0x6e4ce2 main (/usr/local/bin/clang-3.7+0x6e4ce2)
#30 0x7f584afbad5d __libc_start_main (/lib64/libc.so.6+0x1ed5d)
#31 0x6e3819 _start (/usr/local/bin/clang-3.7+0x6e3819)
Stack dump:
0.Program arguments: /usr/local/bin/clang-3.7 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name UnitTestMySQLJob.cpp -mrelocation-model
static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-

[llvm-bugs] [Bug 26257] Assertion `!Parents.empty() && "Found node that is not in the parent map."' failed in ast matcher

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26257

Nico Weber  changed:

   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 26424] New: [CodeGenPrepare] masked scatter/gather with bogus alignment causes assert

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26424

Bug ID: 26424
   Summary: [CodeGenPrepare] masked scatter/gather with bogus
alignment causes assert
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

I'm not sure who to blame for this one. In http://reviews.llvm.org/D16691 , I
noted that the IR verifier doesn't check for constant arg values, so maybe this
is a related problem.

In any case, I created some simple test cases for:
http://reviews.llvm.org/rL259421

The alignment parameter should be meaningless in these tests, so I just made
the value increase with each test. But when I send this IR to llc, it asserts:

$ cat gather.ll
declare <2 x double> @llvm.masked.gather.v2f64(<2 x double*> %ptrs, i32, <2 x
i1> %mask, <2 x double> %passthru)

define <2 x double> @gather_zeromask(<2 x double*> %ptrs, <2 x double>
%passthru)  {
  %res = call <2 x double> @llvm.masked.gather.v2f64(<2 x double*> %ptrs, i32
5, <2 x i1> zeroinitializer, <2 x double> %passthru)
  ret <2 x double> %res
}

$ ./llc gather.ll
Assertion failed: ((Align & (Align-1)) == 0 && "Alignment is not a power of
2!"), function setAlignment, file
/Users/spatel/myllvm/llvm/lib/IR/Instructions.cpp, line 1288.
0  llc  0x0001072c1d5e
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  llc  0x0001072c21a9
PrintStackTraceSignalHandler(void*) + 25
2  llc  0x0001072be949 llvm::sys::RunSignalHandlers() +
425
3  llc  0x0001072c2509 SignalHandler(int) + 345
4  libsystem_platform.dylib 0x7fff9d455eaa _sigtramp + 26
5  libsystem_platform.dylib 0x7fff6b0c98e5 _sigtramp + 3452385877
6  llc  0x0001072c21cb raise + 27
7  llc  0x0001072c2282 abort + 18
8  llc  0x0001072c2261 __assert_rtn + 129
9  llc  0x000106ab94b2
llvm::LoadInst::setAlignment(unsigned int) + 114
10 llc  0x00010531cdd8 llvm::IRBuilder
>::CreateAlignedLoad(llvm::Value*, unsigned int, llvm::Twine const&) + 56
11 llc  0x00010657976e
scalarizeMaskedGather(llvm::CallInst*) + 2062
12 llc  0x00010656abdb (anonymous
namespace)::CodeGenPrepare::optimizeCallInst(llvm::CallInst*, bool&) + 2667
13 llc  0x0001065654b4 (anonymous
namespace)::CodeGenPrepare::optimizeInst(llvm::Instruction*, bool&) + 1876
14 llc  0x000106563991 (anonymous
namespace)::CodeGenPrepare::optimizeBlock(llvm::BasicBlock&, bool&) + 257
15 llc  0x000106561872 (anonymous
namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) + 1026
16 llc  0x000106af760d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 413
17 llc  0x000106af7945
llvm::FPPassManager::runOnModule(llvm::Module&) + 117
18 llc  0x000106af869a (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&) + 2010
19 llc  0x000106af7c2b
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 347
20 llc  0x000106af92e1
llvm::legacy::PassManager::run(llvm::Module&) + 33
21 llc  0x000104fc663c compileModule(char**,
llvm::LLVMContext&) + 19788
22 llc  0x000104fc1886 main + 230
23 libdyld.dylib0x7fff8a4fa5ad start + 1
24 libdyld.dylib0x0002 start + 1974491734
Stack dump:
0.Program arguments: ./llc gather.ll 
1.Running pass 'Function Pass Manager' on module 'gather.ll'.
2.Running pass 'CodeGen Prepare' on function '@gather_zeromask'

-- 
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 26425] New: clang crashes on valid code at -O2 and above on x86_64-linux-gnu running pass “X86 DAG-?=>=?UTF-8?Q?DAG Instruction Selection”

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26425

Bug ID: 26425
   Summary: clang crashes on valid code at -O2 and above on
x86_64-linux-gnu running pass “X86 DAG->DAG
Instruction Selection”
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: helloqi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

The current clang trunk crashes when compiling the following valid code at -O2
and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It might be a regression form 3.3.


$ clang-trunk -v
clang version 3.9.0 (trunk 259346) (llvm/trunk 259345)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/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.3
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.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
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.3.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-trunk abc.c -O2 -c
#0 0x018f1c75 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x18f1c75)
#1 0x018efe86 llvm::sys::RunSignalHandlers()
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x18efe86)
#2 0x018f0075 SignalHandler(int)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x18f0075)
#3 0x7f70b889b340 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#4 0x0136938b llvm::MachineRegisterInfo::constrainRegClass(unsigned
int, llvm::TargetRegisterClass const*, unsigned int)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x136938b)
#5 0x01f21fe3
llvm::InstrEmitter::AddRegisterOperand(llvm::MachineInstrBuilder&,
llvm::SDValue, unsigned int, llvm::MCInstrDesc const*,
llvm::DenseMap,
llvm::detail::DenseMapPair >&, bool, bool, bool)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1f21fe3)
#6 0x01f228f9
llvm::InstrEmitter::AddOperand(llvm::MachineInstrBuilder&, llvm::SDValue,
unsigned int, llvm::MCInstrDesc const*, llvm::DenseMap,
llvm::detail::DenseMapPair >&, bool, bool, bool)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1f228f9)
#7 0x01f27a99 llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool,
bool, llvm::DenseMap, llvm::detail::DenseMapPair >&) (/home/absozero/trunk/root-clang/bin/clang-3.9+0x1f27a99)
#8 0x01f1dad1
llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineBasicBlock::bundle_iterator >&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1f1dad1)
#9 0x01eb262b llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1eb262b)
#10 0x01eb9fea
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1eb9fea)
#11 0x01ebb70f
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1ebb70f)
#12 0x00ff37c4 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0xff37c4)
#13 0x0158160a llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x158160a)
#14 0x01581bd3 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1581bd3)
#15 0x01a1331b clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_pwrite_stream*)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1a1331b)
#16 0x01f54bc6
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1f54bc6)
#17 0x004d clang::ParseAST(clang::Sema&, bool, bool)
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x04d)
#18 0x01cdc646 clang::FrontendAction::Execute()
(/home/absozero/trunk/root-clang/bin/clang-3.9+0x1c

[llvm-bugs] [Bug 26383] QualType::print prints "&" when PrintingPolicy.SuppressSpecifiers is true for reference types

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26383

Richard Smith  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Smith  ---
(In reply to comment #5)
> What I mean is that I want to only skip the specifiers of the function.
> About what I want, I've already explained - I want to explicitly instantiate
> functions of template types:
> 
> template const QString & QList::first() const;

Here, 'const' and 'QString' are both specifiers, so you'll need to produce
those somehow. One possibility would be:

 1) print the declaration with SuppressSpecifiers = true
 2) get the function's return type and print it to a string stream with a
marker string for the declared name:
  FD->getType()->castAs()->getReturnType().print(Out,
Policy, "<<>>");
 3) take the string from step 2, remove the marker and everything after it, and
glue that on the start of the declaration from step 1.

In any case, I'm closing this bug as invalid, as SuppressSpecifiers is working
as intended.

-- 
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 26427] New: Template recursion can get error reporting into an infinite loop

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26427

Bug ID: 26427
   Summary: Template recursion can get error reporting into an
infinite loop
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: r0maikx...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Error reporting can get into a very long (but probably not really infinite
loop).

The following snippet reproduces it nicely:

#include 

template
void f(T t) {
   return f(std::make_unique(t));
}

int main() {
f(0);
}

I tried to compile it using: clang++ -std=c++14 main.cpp
The compiler starts spitting out long recursive template unique_ptr types.

Tested with r259432 but also happens in older versions as well.

Speculation:
If the make_unique call is replaced with an instantiation of a simpler template
class, then the built in recursion protection of clang kicks in, and it skips
the middle few hundred frames of the instantiation chain in the error message.
In any case you'll see that there is a very deeply nested type on the bottom of
the trace. My suspicion is that since unique_ptr has a more complicated
template interface, it simply takes much more characters to print a single
level of this nesting, and this causes the seemingly endless stream of errors.

-- 
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 25757] dsymutil generates warnings on local symbols (?)

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=25757

Nenad Vukicevic  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Nenad Vukicevic  ---
To clarify this failure:

- The compiler used to generate object files is LLVM/Clang from Apple or GCC
built on Apple.  For all practical purposes we only pre-process source files to
generate the final compilation source file.

- We get warnings only from GCC as GCC driver invokes dysmutil at the end of
the run. LLVM driver does not invoke dysmutil, but if you invoke it by hand on
the executable you will get the same warnings.

- Out of 1000 tests we get failures only on tests that have more then 20 of
these kind of symbols (handful of them).  The other files do not produce
warnings but, based on your response, dsymutil is silently doing the wrong
thing on these files too.

Would it be helpful if I provide you with a file that does not generate
warnings?

-- 
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 10003] SelectionDAG instruction selection performs CSE on nodes with debug information

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=10003

Reid Kleckner  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||r...@google.com
 Resolution|WONTFIX |---

--- Comment #10 from Reid Kleckner  ---
Similar issue, consider the following code and the .loc directives in the
assembly:

volatile int x;
extern "C" void exit(int);
int main() {
  x += 24;
  x += 2;
  x += 3;
  x += 4;
  exit(24);
}

addl$24, "?x@@3HC"(%rip)
.loc1 5 5   # t.cpp:5:5
addl$2, "?x@@3HC"(%rip)
.loc1 6 5   # t.cpp:6:5
addl$3, "?x@@3HC"(%rip)
.loc1 7 5   # t.cpp:7:5
addl$4, "?x@@3HC"(%rip)
.loc1 4 5   # t.cpp:4:5
movl$24, %ecx
.loc1 8 3   # t.cpp:8:3
callq   exit
.loc1 9 1   # t.cpp:9:1
xorl%eax, %eax
addq$40, %rsp
retq

We shouldn't step backwards to line 4 between line 7 and 8. I'm pretty sure
this is DAG CSE, but I could be wrong.

I might take a look at this.

-- 
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 26428] New: LICM: Ignore loop exits which don't exit on first iteration when computing isGuaranteedToExecute

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26428

Bug ID: 26428
   Summary: LICM: Ignore loop exits which don't exit on first
iteration when computing isGuaranteedToExecute
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When computing the isGuaranteedToExecute predicate in LICM (used for satisfying
dereferenceability and memory model legality questions), we can ignore any
exiting blocks where the exit condition is known not to exit on the first
iteration.  

A motivating example might be something like this:
sum = 0;
for (int i = 0; i < 100; i++)
  if (i > 20) break;
  // g_idx is a global and doesn't alias a
  sum += a[g_idx]
}

We can hoist the load of g_idx out of the loop even if we don't know that g_idx
is dereferenceable since doing so can not change the location of a fault. 
Specifically, we know that the loop exit can't be taken on the first iteration
since (0 > 20) == false.

-- 
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 26429] New: LICM Store promotion when store found in preheader

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26429

Bug ID: 26429
   Summary: LICM Store promotion when store found in preheader
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When doing store promotion, we have to satisfy a legality constraint which
prevents us from inserting any new stores to locations visible to other threads
along any dynamic path.  Today, we do this by finding a store inside the loop
guaranteed to execute on all paths through the loop.  We could also satisfy
this legality constraint by finding a store immediately before the loop and
removing that one as part of the transformation.  

Motivating example:
int location;
void foo() {
  int start = location;
  for (int i = 0; i < 1000; i++) {
// Key point is we can't establish the store in the loop to always exit
if (volatile load) break;
location = start + i;
  }
}

In general, any store outside the loop which is post-dominated by the loop
header and dominates the loop header without intervening memory access would be
legal, but in practice, we probably want to limit the search to the preheader
and possible one or two immediately preceding blocks.  (This might also be
interesting to express over the newly added MemorySSA form!)

Note that the same argument applies to a store which post-dominates all exits
from the loop.  Without any real evidence, I suspect that case might be more
rare.

-- 
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 26430] New: Flatten two comparisons against a constant power of two into an OR + cmp

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26430

Bug ID: 26430
   Summary: Flatten two comparisons against a constant power of
two into an OR + cmp
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Given an IR fragment like the following:
bb1:
  %cmp1 = icmp ult i32 %a, 16
  br i1 %cmp1, label %bb2, label %exit1 ;; rarely not taken
bb2:
  %cmp2 = icmp ult i32 %b, 16
  br i1 %cmp2, label %fallthrough, label %exit2 ;; rarely not taken
fallthrough:
  ...

We can rewrite this as:
bb1:
  %or = or i32 %a, %b
  %cmp1 = icmp ult i32 %or, 16
  br i1 %cmp1, label %fallthrough, label %common_exit ;; rarely not taken
fallthrough:
  ...

common_exit:
  %cmp2 = icmp ult i32 %a, 16
  br i1 %cmp2, label %exit1, label %exit2 ;; rarely not taken


This transform is likely fairly target specific and produces IR which is hard
for other passes to analyse.  Given that, it probably belongs fairly late.  CGP
might be one reasonable place.

The general conditions under which this will apply are:
- Two successive tests against the same constant on different values
- The tests form what is essentially a bit test.  i.e. ult for 2^X or ule for
2^X-1.
- The first branch fails rarely.
- No side effecting instructions in %bb2 and few total instructions (we end up
essentially speculating them)

-- 
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 26431] New: i/o stream of based enum gives ambiguity error

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26431

Bug ID: 26431
   Summary: i/o stream of based enum gives ambiguity error
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: i...@millcomputing.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

This source:
#include
enum foo : short  {};
extern foo bar;
int main(int argc, char** argv) {
std::cerr << bar;
return 0;
}
when compiled with:
s8:~/mill/specializer$ clang  -std=c++11 -v
clang version 3.7.0 (branches/release_37 242873)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.9.2
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.9.2
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

gives this diagnostic:

test.cc:6:12: error: use of overloaded operator '<<' is ambiguous (with operand
  types 'ostream' (aka 'basic_ostream') and 'foo')
std::cerr << bar;
~ ^  ~~~
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:178:7:
note:
  candidate function
  operator<<(short __n);
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:189:7:
note:
  candidate function
  operator<<(int __n);
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:166:7:
note:
  candidate function
  operator<<(long __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:170:7:
note:
  candidate function
  operator<<(unsigned long __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:174:7:
note:
  candidate function
  operator<<(bool __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:181:7:
note:
  candidate function
  operator<<(unsigned short __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:192:7:
note:
  candidate function
  operator<<(unsigned int __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:201:7:
note:
  candidate function
  operator<<(long long __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:205:7:
note:
  candidate function
  operator<<(unsigned long long __n)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:220:7:
note:
  candidate function
  operator<<(double __f)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:224:7:
note:
  candidate function
  operator<<(float __f)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:232:7:
note:
  candidate function
  operator<<(long double __f)
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:482:5:
note:
  candidate function [with _Traits = std::char_traits]
operator<<(basic_ostream& __out, char __c)
^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:476:5:
note:
  candidate function [with _CharT = char, _Traits = std::char_traits]
operator<<(basic_ostream<_CharT, _Traits>& __out, char __c)
^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:488:5:
note:
  candidate function [with _Traits = std::char_traits]
operator<<(basic_ostream& __out, signed char __c)
^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/ostream:493:5:
note:
  candidate function [with _Traits = std::char_traits]
operator<<(basic_ostream& __out, unsigned char __c)
^
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 20807] [EarlyCSE, Missed Opt] "unordered" loads and stores can be removed

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=20807

listm...@philipreames.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from listm...@philipreames.com ---
Implemented

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 22583] [EarlyCSE] Missed trivial dead store case

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=22583

listm...@philipreames.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from listm...@philipreames.com ---
Implemented.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 26432] New: Archive name is not printed in diagnostic.

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26432

Bug ID: 26432
   Summary: Archive name is not printed in diagnostic.
   Product: lld
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: chisophu...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Currently, when LLD issues a "duplicate symbol" error, where one symbol is in
an archive, the name of the archive isn't printed. For example, the diagnostic
will be something like:

duplicate symbol: foo in foo.o and some/long/path/to/other.o

For clarity, it should be something like:

duplicate symbol: foo in some/long/path/to/unexpected.a(foo.o) and
some/long/path/to/other.o

It is hard to communicate in a reduced test case, but in practice the path to
the .a file is sometimes not obvious. Especially when there are two archives,
you can end up with e.g. "duplicate symbol: foo in foo.o and foo.o", which is
not very helpful.

-- 
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 26433] New: Can't build LLVM with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON

2016-02-01 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=26433

Bug ID: 26433
   Summary: Can't build LLVM with -D
LLVM_USE_INTEL_JITEVENTS:BOOL=ON
   Product: new-bugs
   Version: 3.8
  Hardware: PC
OS: All
Status: NEW
  Severity: release blocker
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: evgeniy.tyu...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 15798
  --> https://llvm.org/bugs/attachment.cgi?id=15798&action=edit
Log extract

Can't build LLVM with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON

Log exempt and steps to reproduce are attached.

The problem is with a missing dependency on llvm/IR/Attributes.inc generating
target in lib/ExecutionEngine/IntelJITEvents/CMakeLists.txt

The problem is visible both on 3.8 and trunk.

My vision of the patch 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