[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[cpphackster at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #20 from Daniel Elliott  ---
cool. just tried that.

gets gcc down to 

GCC:
---
ifStandard  596892 ns   
ifNoConditional 148075 ns <--- with "result[n] = tab[item > .5f];" trick

Clang:(no change)
ifStandard   88777 ns   
ifNoConditional  89818 ns  

--

still clang is 1.64x faster. had a look at the assembly. My limited
understanding makes me think that the ucomiss is not fully vectorized and the
clang one is (clangs ucomiss %xmm0,%xmm1 vs gcc's ucomiss 0x218b4(%rip),%xmm0).
Feel free to correct me if I am wrong.


clang:

   movss  0x61a80(%r15,%rcx,1),%xmm1
22.95% xor%eax,%eax
   ucomiss %xmm0,%xmm1
13.81% seta   %al
22.55% mov0x4335d0(,%rax,4),%eax
4.31%  mov%eax,0x61a80(%rbx,%rcx,1)
22.03% movss  0x61a84(%rbx,%rcx,1),%xmm1
0.40%  movss  %xmm1,0xc(%rsp)
13.93% add$0x4,%rcx
   jne404b50 


gcc:

14.45% movss  0x0(%r13,%rax,1),%xmm0
0.18%  xor%edx,%edx
21.27% ucomiss 0x218b4(%rip),%xmm0# 426bf4 <_IO_stdin_used+0x34>
16.84% seta   %dl
21.79% movss  0x8(%rsp,%rdx,4),%xmm0
1.41%  movss  %xmm0,(%r12,%rax,1)
23.94% add$0x4,%rax
   cmp$0x61a80,%rax
   jne405330 

[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #19 from Marc Glisse  ---
For the "ifno" case, llvm turns

(item>.5f)?1.:0.

into (cheating on the syntax, we can't do bit_and on float in C)

((item>.5f)?mask:0.) & 1.

where mask is all one bits, and this uses the SSE comparison instruction that
generates said mask or 0.

llvm is missing the extra trick that the following multiplication can be merged
into this, to do directly & .7f.

[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #18 from Marc Glisse  ---
For the "if" case, llvm turns:

if (myVector[n] > 0.5){
result[n] = 0.8f;
}
else {
result[n] = 0.1f;
}

into

const float tab[2] = { .8f, .1f };
result[n] = tab[item > .5f];

[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837

--- Comment #9 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #8)
> In any case, please always set the Target Milestone when closing a bug.

I thought that was just for regressions...

[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[cpphackster at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #17 from Daniel Elliott  ---
my previous comment above meant to say this (change from float to int)

Interestingly for the gcc case, if I return float from the when_greater_than
function (which is just doing x > y ? 1: 0;  then it matches gcc ifStandard
speed exactly but if I return an > int << then goes down to the ~191000
ns speed shown above. But still not as fast as both clang cases.

[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[cpphackster at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #16 from Daniel Elliott  ---
Created attachment 44001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44001&action=edit
revised benchmark w/different approach

[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations

[cpphackster at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466

--- Comment #15 from Daniel Elliott  ---
Good catch johnathan on the return type of max. (PS also enjoyed your accu talk
on youtube).

I also have been messing around with the benchmark a bit and have come to the
conclusion that the sign function and the max isn't really necesary. simple
ternary operators seems to do a better job.

However, gcc still seems to be slower in these cases compared to clang.

Ive attached benchmarkv2 which on my ivy bridge 2013 macbook pro gets

GCC:
ifStandard  600741 ns 600594 ns   1056
ifNoConditional 191043 ns 191000 ns   3694

Clang:
ifStandard   88777 ns  88726 ns   7439
ifNoConditional  89818 ns  89777 ns   7910

Interestingly for the gcc case, if I return float from the when_greater_than
function (which is just doing x > y ? 1: 0;  then it matches gcc ifStandard
speed exactly but if I return a float then goes down to the ~191000 ns speed
shown above. But still not as fast as both clang cases.  

Have to say this is a lot of fun and thanks everyone for looking at this!

[Bug libitm/85489] New: config/x86/sjlj.S should use unsigned integer to unwind shadow stack

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85489

Bug ID: 85489
   Summary: config/x86/sjlj.S should use unsigned integer to
unwind shadow stack
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

config/x86/sjlj.S has

cmpq$255, %rcx
jle .L3 
^^^ Should be "jbe".
movl$255, %edi
.p2align 4,,10
.p2align 3
.L4:
incsspq %rdi
subq$255, %rcx
cmpq$255, %rcx
jg  .L4
^^^ Should be "ja".
.L3:
incsspq %rcx
.L1:

and

cmpl$255, %ecx
jle .L3
^^^ Should be "jbe".
pushl   %eax
movl$255, %eax
.p2align 4,,10
.p2align 3
.L4:
incsspd %eax
subl$255, %ecx
cmpl$255, %ecx
jg  .L4
^^^ Should be "ja".
popl%eax
.L3:
incsspd %ecx
.L1:


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full bugs

[Bug c/85488] New: segmentation fault when compiling code using the ordered(n) clause in OpenMP 4.5

[chunhualiao at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85488

Bug ID: 85488
   Summary: segmentation fault when compiling code using the
ordered(n) clause in OpenMP 4.5
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chunhualiao at gmail dot com
  Target Milestone: ---

Created attachment 44000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44000&action=edit
this is the input file to trigger the error

gcc -fopenmp doall2-ordered-orig-no.c


doall2-ordered-orig-no.c: In function ‘main’:
doall2-ordered-orig-no.c:62:9: internal compiler error: Segmentation fault
 #pragma omp parallel for ordered(2)
 ^~~
0x9d0ebf crash_signal
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/toplev.c:337
0x7adfb0 gsi_for_stmt(gimple*)
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/gimple-iterator.c:614
0x8d8f42 expand_omp_ordered_source_sink
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:2260
0x8d8f42 expand_omp_for_generic
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:2986
0x8daff3 expand_omp_for
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:5883
0x8dbf2a expand_omp
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:7894
0x8dc6d6 expand_omp
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:7880
0x8de5ad execute_expand_omp
   
/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/7.1.0/mpc/1.0/mpfr/3.1.2/gmp//workspace/gcc-7.1.0/gcc/omp-expand.c:8118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/85487] New: Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio

[austinpmorton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487

Bug ID: 85487
   Summary: Support '#pragma region' and '#pragma endregion' to
allow code folding with Visual Studio
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: austinpmorton at gmail dot com
  Target Milestone: ---

#pragma region is a feature introduced by Microsoft in order to allow manual
grouping and folding of code within Visual Studio.  It is entirely ignored by
the compiler.  Clang has supported this feature since 2012 when in MSVC
compatibility mode, and enabled it across the board 3 months ago.

As it stands, you cannot use #pragma region within GCC without disabling
unknown pragma warnings, which is not advisable.

I propose GCC adopt "#pragma region" and "#pragma endregion" in order to
alleviate these issues.  Because the pragma has no purpose at compile time, the
implementation would be trivial.


Microsoft Documentation on the feature:
https://docs.microsoft.com/en-us/cpp/preprocessor/region-endregion

LLVM change which enabled pragma region across the board:
https://reviews.llvm.org/D42248

Example usage and resulting compiler output:
https://godbolt.org/g/uJv6u4

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
Patch committed in r259535.

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 20 23:43:51 2018
New Revision: 259535

URL: https://gcc.gnu.org/viewcvs?rev=259535&root=gcc&view=rev
Log:
PR c/85365 -  -Wrestrict false positives with -fsanitize=undefined

gcc/ChangeLog:

PR c/85365
* gimple-fold.c (gimple_fold_builtin_strcpy): Suppress -Wrestrict
for null pointers.
(gimple_fold_builtin_stxcpy_chk): Same.
* gimple-ssa-warn-restrict.c (check_bounds_or_overlap): Same.

gcc/testsuite/ChangeLog:

PR c/85365
* gcc.dg/Wrestrict-15.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85456] PowerPC: Using -mabi=ieeelongdouble calls wrong function for __builtin_powi.

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85456

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 259533.

[Bug target/85456] PowerPC: Using -mabi=ieeelongdouble calls wrong function for __builtin_powi.

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85456

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Fri Apr 20 22:36:48 2018
New Revision: 259534

URL: https://gcc.gnu.org/viewcvs?rev=259534&root=gcc&view=rev
Log:
[libgcc]
2018-04-20  Michael Meissner  

PR target/85456
* config/rs6000/_powikf2.c: New file.  Add support for the
__builtin_powil function when long double is IEEE 128-bit floating
point.
* config/rs6000/float128-ifunc.c (__powikf2_resolve): Add
__powikf2 support.
(__powikf2): Likewise.
* config/rs6000/quad-float128.h (__powikf2_sw): Likewise.
(__powikf2_hw): Likewise.
(__powikf2): Likewise.
* config/rs6000/t-float128 (fp128_ppc_funcs): Likewise.
* config/rs6000/t-float128-hw (fp128_hw_func): Likewise.
(_powikf2-hw.c): Likewise.

[gcc]
2018-04-20  Michael Meissner  

PR target/85456
* config/rs6000/rs6000.c (init_float128_ieee): Add support to call
__powikf2 when long double is IEEE 128-bit.

[gcc/testsuite]
2018-04-20  Michael Meissner  

PR target/85456
* gcc.target/powerpc/pr85456.c: New test.


Added:
branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr85456.c
branches/ibm/gcc-7-branch/libgcc/config/rs6000/_powikf2.c
Modified:
branches/ibm/gcc-7-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-7-branch/gcc/testsuite/ChangeLog.ibm
branches/ibm/gcc-7-branch/libgcc/ChangeLog.ibm
branches/ibm/gcc-7-branch/libgcc/config/rs6000/float128-ifunc.c
branches/ibm/gcc-7-branch/libgcc/config/rs6000/quad-float128.h
branches/ibm/gcc-7-branch/libgcc/config/rs6000/t-float128
branches/ibm/gcc-7-branch/libgcc/config/rs6000/t-float128-hw

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315

--- Comment #9 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #8)
> > I asked Peter about that yesterday.  The access to *p in your example is 
> > still
> > meant to be undefined even under the proposed provenance rules.  Here's his
> 
> Even with -fno-provenance?

With -fno-provenance the access would be valid under the proposed rules.

> I think for the compiler "unspecified" works as well - we can still
> unconditionally optimize it to return false, correct?

Correct.

[Bug target/85486] New: [og7, nvptx] ref-1.C fails with vector length 128

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486

Bug ID: 85486
   Summary: [og7, nvptx] ref-1.C fails with vector length 128
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Minimal example:
...
/* { dg-do run } */

extern "C" int printf (char const *, ...);

#pragma acc routine vector
void __attribute__((noinline, noclone))
Vector (int *ptr, int n, const int &inc)
{
  #pragma acc loop vector
  for (unsigned ix = 0; ix < n; ix++)
ptr[ix] += inc;
}

int
main (void)
{
  const int n = 32, m=32;

  int ary[m][n];
  unsigned ix,  iy;

  for (ix = m; ix--;)
for (iy = n; iy--;)
  ary[ix][iy] = (1 << 16) + (ix << 8) + iy;

  int err = 0;

#pragma acc parallel copy(ary) vector_length(128)
  {
Vector (&ary[0][0], m * n, (1<<24) - (1<<16));
  }

  for (ix = m; ix--;)
for (iy = n; iy--;)
  if (ary[ix][iy] != ((1 << 24) + (ix << 8) + iy))
{
  printf ("ary[%u][%u] = %x expected(II) %x\n",
  ix, iy, ary[ix][iy], ((1 << 24) + (ix << 8) + iy));
  err++;
}

  if (err)
{
  printf ("%d failed\n", err);
  return 1;
 }

  return 0;
}
...

The problem is that we launch the region with vector length 128:
...
//:FUNC_MAP "main$_omp_fn$0", 0x1, 0x1, 0x80
...
but the Vector routine is generate assuming vector length 32:
...
.visible .func _Z6VectorPiiRKi (.param.u64 %in_ar0, .param.u32 %in_ar1,
.param.u64 %in_ar2)
{
.reg.u64 %ar0;
ld.param.u64 %ar0, [%in_ar0];
.reg.u32 %ar1;
ld.param.u32 %ar1, [%in_ar1];
.reg.u64 %ar2;
ld.param.u64 %ar2, [%in_ar2];
.reg.u64 %r66;
.reg.u64 %r67;
.reg.u32 %r68;
.reg.u64 %r75;
.reg.u64 %r76;
.reg.u32 %r77;
.reg.u64 %r78;
.reg.pred %r79;
.reg.u64 %r80;
.reg.u32 %r81;
.reg.u32 %r82;
.reg.u32 %r83;
.reg.u64 %r84;
.reg.u64 %r85;
.reg.u64 %r86;
.reg.u64 %r87;
.reg.u64 %r88;
.reg.u32 %r89;
.reg.u32 %r90;
.reg.u32 %r91;
.reg.pred %r92;
.reg.u32 %r93;
.reg.u32 %r94;
.reg.u32 %r95;
.reg.u32 %r96;
.reg.pred %r97;
{
.reg.u32%x;
mov.u32 %x, %tid.x;
setp.ne.u32 %r97, %x, 0;
}
@%r97   bra $L5;
mov.u64 %r76, %ar0;
mov.u32 %r77, %ar1;
mov.u64 %r78, %ar2;
// fork 4;
$L5:
// forked 4;
mov.b64 {%r93,%r94}, %r76;
shfl.idx.b32%r93, %r93, 0, 31;
shfl.idx.b32%r94, %r94, 0, 31;
mov.b64 %r76, {%r93,%r94};
shfl.idx.b32%r77, %r77, 0, 31;
mov.b64 {%r95,%r96}, %r78;
shfl.idx.b32%r95, %r95, 0, 31;
shfl.idx.b32%r96, %r96, 0, 31;
mov.b64 %r78, {%r95,%r96};
mov.u32 %r68, %tid.x;
setp.le.s32 %r79, %r77, %r68;
@%r79   bra $L2;
cvt.s64.s32 %r66, %r68;
shl.b64 %r80, %r66, 2;
add.u64 %r67, %r76, %r80;
add.u32 %r81, %r77, -1;
sub.u32 %r82, %r81, %r68;
shr.u32 %r83, %r82, 5;
cvt.u64.u32 %r84, %r83;
shl.b64 %r85, %r84, 5;
add.u64 %r86, %r85, %r66;
shl.b64 %r87, %r86, 2;
add.u64 %r88, %r76, 128;
add.u64 %r75, %r87, %r88;
$L3:
ld.u32  %r90, [%r67];
ld.u32  %r91, [%r78];
add.u32 %r89, %r90, %r91;
st.u32  [%r67], %r89;
add.u64 %r67, %r67, 128;
setp.ne.u64 %r92, %r67, %r75;
@%r92   bra $L3;
$L2:
// joining 4;
// join 4;
ret;
}
...

[Bug target/85485] New: Remove -mcet

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85485

Bug ID: 85485
   Summary: Remove -mcet
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

After removal of -mibt, -mcet becomes just an alias for -mshstk.
-mcet can be removed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full bugs

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82805

--- Comment #7 from Martin Jambor  ---
According to my latest numbers. 454.alculix compiled with gcc 7 is 3% slower
than gcc 6 at -O2 but trunk (r259234) is as fast as gcc 6.

[Bug c/85361] Variable length array allowed in c89/90

[whh8b at virginia dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361

Will Hawkins  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Will Hawkins  ---
Thanks to Joseph, I now realize that this was an invalid bug -- as in, it
wasn't a bug at all. Thanks!

[Bug c/85361] Variable length array allowed in c89/90

[whh8b at virginia dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361

--- Comment #4 from Will Hawkins  ---
(In reply to jos...@codesourcery.com from comment #3)
> See the documentation of -std=, regarding base standards.
> 
> # The compiler can accept several base standards, such as @samp{c90} or
> # @samp{c++98}, and GNU dialects of those standards, such as
> # @samp{gnu90} or @samp{gnu++98}.  When a base standard is specified, the
> # compiler accepts all programs following that standard plus those
> # using GNU extensions that do not contradict it.  For example,
> # @option{-std=c90} turns off certain features of GCC that are
> # incompatible with ISO C90, such as the @code{asm} and @code{typeof}
> # keywords, but not other GNU extensions that do not have a meaning in
> # ISO C90, such as omitting the middle term of a @code{?:}
> # expression. On the other hand, when a GNU dialect of a standard is
> # specified, all features supported by the compiler are enabled, even when
> # those features change the meaning of the base standard.  As a result, some
> # strict-conforming programs may be rejected.  The particular standard
> # is used by @option{-Wpedantic} to identify which features are GNU
> # extensions given that version of the standard. For example
> # @option{-std=gnu90 -Wpedantic} warns about C++ style @samp{//}
> # comments, while @option{-std=gnu99 -Wpedantic} does not.

Thank you for patiently pointing that out to me. I would not have noticed the
subtlety had you not mentioned it explicitly. I am sorry for being so dense. I
hope that I didn't waste anyone's time. I am going to close this now. 

Thanks again!
Will

[Bug target/85456] PowerPC: Using -mabi=ieeelongdouble calls wrong function for __builtin_powi.

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85456

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Fri Apr 20 21:27:08 2018
New Revision: 259533

URL: https://gcc.gnu.org/viewcvs?rev=259533&root=gcc&view=rev
Log:
[libgcc]
2018-04-20  Michael Meissner  

PR target/85456
* config/rs6000/_powikf2.c: New file.  Add support for the
__builtin_powil function when long double is IEEE 128-bit floating
point.
* config/rs6000/float128-ifunc.c (__powikf2_resolve): Add
__powikf2 support.
(__powikf2): Likewise.
* config/rs6000/quad-float128.h (__powikf2_sw): Likewise.
(__powikf2_hw): Likewise.
(__powikf2): Likewise.
* config/rs6000/t-float128 (fp128_ppc_funcs): Likewise.
* config/rs6000/t-float128-hw (fp128_hw_func): Likewise.
(_powikf2-hw.c): Likewise.

[gcc]
2018-04-20  Michael Meissner  

PR target/85456
* config/rs6000/rs6000.c (init_float128_ieee): Add support to call
__powikf2 when long double is IEEE 128-bit.

[gcc/testsuite]
2018-04-20  Michael Meissner  

PR target/85456
* gcc.target/powerpc/pr85456.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr85456.c
trunk/libgcc/config/rs6000/_powikf2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/config/rs6000/float128-ifunc.c
trunk/libgcc/config/rs6000/quad-float128.h
trunk/libgcc/config/rs6000/t-float128
trunk/libgcc/config/rs6000/t-float128-hw

SAP NetWeaver Users list

[Celina Clarke]

Hello there,

I would like to know if you are interested in acquiring SAP NetWeaver Users 
list.

Information fields: Names, Title, Email, Phone, Company Name, Company URL, 
Company physical address, SIC Code, Industry, Company Size (Revenue and 
Employee).

NOTE: If this is not relevant to you please get back to me with your Target 
Market, we cater to all types of target market available.

Let me know your thoughts on this and I will get back with more information for 
your review.

Await your response!
Regards,
Celina Clarke
Demand Generation Manager

If you do not wish to receive further emails, please respond with "Leave Out" 
or "Unsubscribe" in subject line

[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #8 from Paolo Carlini  ---
In any case, please always set the Target Milestone when closing a bug.

[Bug bootstrap/54696] Makefile doesn't propagate CPPFLAGS to host libraries

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696

Eric Gallager  changed:

   What|Removed |Added

 CC|egall at gwmail dot gwu.edu|egallager at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78251

--- Comment #3 from Eric Gallager  ---
semi-related: bug 78251

[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Eric Gallager  ---
(In reply to Vegard Nossum from comment #5)
> This looks like it has been fixed, maybe somebody can confirm and change
> status.

Output is now:

$ /usr/local/bin/g++ -c -std=c++14 -g -Wall -Wextra 81837.cc
81837.cc: In function 'int main()':
81837.cc:18:42: error: name 'align' used in a GNU-style designated initializer
for an array
   chunk = new Unit  [10] {.align = 0};
  ^
81837.cc:18:42: error: could not convert '0' from 'int' to 'Unit'
$

So confirmed that there's no more ICE. I think the 2 remaining errors are
different enough so as not to need to be de-duplicated, but feel free to open a
new bug if you think there should only be one.

[Bug c++/65923] False positive for warning about literal operator suffix and using

[TonyELewis at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923

--- Comment #9 from Tony E Lewis  ---
I'm so delighted to see:

  #include 
  #include 

  using std::literals::chrono_literals::operator""s;
  using std::literals::string_literals::operator""s;

...compiling cleaning on Godbolt.

Thanks for this Ville.

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68397

--- Comment #5 from emsr at gcc dot gnu.org ---
We fixed this a long time ago.

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68397

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from emsr at gcc dot gnu.org ---
We fixed this forever ago.

[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from emsr at gcc dot gnu.org ---
We fixed this back in 1017-11-18.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #20 from Michael Meissner  ---
I'm sorry long double doesn't seem to work on your system.  If your system does
not have the appropriate long double libraries, you probably need to use the
--with-long-double-64 option to make long double use the double type.  Or you
(or somebody else using the system) need to submit patches, so the compiler
calls whatever is the names of the long double emulation on your system.

With the current compiler, as has been stated, we cannot build libquadmath
unless __float128 is supported.  Right now, the only support is for the
following systems:

1) Little endian power8/9 systems
2) Big endian power7/8/9 systems where you use the --with-cpu= option,
where  is power7, power8, or power9.

There just isn't support for a IEEE 128-bit floating point type, unless you
have the VSX (vector scalar extensions) that were first introduced in power7.

The __gcc_q{add,sub,mul,div} come from the libgcc/config/rs6000/ibm-ldouble.c
file.  Perhaps it is not configured for your system.

[Bug rtl-optimization/79985] ICE in code_motion_path_driver, at sel-sched.c:6580

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985

--- Comment #7 from Alexander Monakov  ---
Or rather like this:

diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 95e1e0df2d5..732705c0385 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -3207,11 +3207,11 @@ df_insn_refs_collect (struct df_collection_rec
*collection_rec,
   if (CALL_P (insn_info->insn))
 df_get_call_refs (collection_rec, bb, insn_info, flags);

-  if (asm_noperands (PATTERN (insn_info->insn)) >= 0)
+  if (GET_CODE (PATTERN (insn_info->insn)) == ASM_INPUT)
 for (unsigned i = 0; i < FIRST_PSEUDO_REGISTER; i++)
   if (global_regs[i])
{
- /* As with calls, asm statements reference all global regs. */
+ /* As with calls, basic asms reference all global regs. */
  df_ref_record (DF_REF_BASE, collection_rec, regno_reg_rtx[i],
 NULL, bb, insn_info, DF_REF_REG_USE, flags);
  df_ref_record (DF_REF_BASE, collection_rec, regno_reg_rtx[i],

[Bug fortran/85448] Report binding label clash with a global identifyer

[francois.jacq at irsn dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448

--- Comment #8 from francois.jacq at irsn dot fr ---
(In reply to Thomas Koenig from comment #7)
> As quoted by Steve Lionel on c.l.f (F2008, 16.2, para 2):
> 
> "The global identifier of an entity shall not be the same as the global
> identifier of any other entity. Furthermore, a
> binding label shall not be the same as the global identifier of any other
> global entity, ignoring differences in case."
> 
> So, the code is invalid. Since this is not a constraint, the compiler
> can do anything it pleases.
> 
> It would be nice to have an error message, though; should be straightforward
> to implement.

Unfortunately, if you look into the comment #2, you will understand that the
situation is a little bit more subtile.

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381

Tom de Vries  changed:

   What|Removed |Added

  Attachment #43992|0   |1
is obsolete||

--- Comment #9 from Tom de Vries  ---
Created attachment 43999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43999&action=edit
Tentative patch inserting dummy instructions

(In reply to Tom de Vries from comment #7)
> We may wanna insert dummy ops inbetween (it would be nice if something less
> heavy than a membar.cta will work).

This patch implements this approach. I've reported the bug at nvidia and see if
they come up with a better or more restricted workaround.

[Bug tree-optimization/85406] Unnecessary blend when vectorizing short-cutted calculations

[linux at carewolf dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406

--- Comment #6 from Allan Jensen  ---
Yeah, the a==255 was actually not a case I would expect the compiler to solve,
which is why I changed the example to the a==0 case, which should be solveable
using existing constant propagation.

Note you can put both short-cuts in, though as it standards only gcc 7 and 8
can vectorize it with two conditions, so we cant use that in general code as we
need it to be fast elsewhere too.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #35 from Martin Sebor  ---
Here are the proposed changes:

Pointer Provenance:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-corrigendum

Trap Representations:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2220.htm#proposed-technical-corrigendum

Unspecified Values:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2221.htm#proposed-technical-corrigendum

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #34 from Martin Sebor  ---
The questions in N2223 and the other documents are there to provide background
and justification for the proposed changes (the questions come surveys they
sent to various forums).  The proposed words are at the end of each of the
papers referenced from N2223.  I don't have the sense that N2223 covers this
case but it's closely related.

Memcpy and memmove transfer the effective type only to objects with no declared
type (i.e., allocated objects):

  int i = 123;
  void *p = malloc (sizeof i);
  memcpy (p, &i, sizeof i);   // *p's effective type is now int

This standard mentions just memcpy, memmove, and copies via a character type,
so other mechanisms do not transfer the effective type.  (The effective type of
other (typed) storage is that of its declared type.)  Memory is only allowed to
be accessed via an lvalue compatible with its effective type (or char), so
above, what's at p can only accessed as *(int*)p.

I think in the use case below:

   struct { int i; char buf[4]; } s, r;
   *(float *)s.buf = 1.;
   r = s;

the aggregate copy has to be viewed as a recursive copy of each of its members
and copying buf[4] must be viewed as a memcpy,  Char is definitely special (it
can accesses anything with impunity, even indeterminate values).  That said, I
don't think the rules allow char arrays to be treated as allocated storage so
while the store to s.buf via float* may be valid it doesn't change the
effective type of s.buf and so the only way to read the float value stored in
it is to copy it byte-by-byte (i.e., copy the float representation) to an
object whose effective type is float.  Some of the papers that deal with the
effective type rules might touch on this (e.g., DR 236, Clark's N1520

[Bug tree-optimization/85478] ICE with single element vector

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #6 from Andreas Krebbel  ---
The difference I have seen so far was triggered by building the cross with
"--without-headers". As a result the detected glibc version is 0.0:

config.log:

configure:28145: checking for target glibc version
configure:28169: result: 0.0

This in turn fails to set the proper default for the long double data type in
configure:

if test $glibc_version_major -gt 2 \
  || ( test $glibc_version_major -eq 2 && test $glibc_version_minor -ge 4 );
then :
  gcc_cv_target_ldbl128=yes
else
  ...


configuring the cross --with-long-double-128 makes the first set of differences
to disappear. However, the testcase still doesn't ICE when compiled with the
cross.

I will retry with a full cross. There appear to be more settings depending on
the Glibc version.

[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722

[sebastian.peryt at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473

--- Comment #3 from Sebastian Peryt  ---
Proposed patch sent to ML:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01011.html

[Bug testsuite/85483] Many failures on test gcc.target/aarch64/sve/vcond_1.c

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85483

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Apr 20 16:31:19 2018
New Revision: 259526

URL: https://gcc.gnu.org/viewcvs?rev=259526&root=gcc&view=rev
Log:
PR testsuite/85483: Move aarch64/sve/vcond_1.c test to g++.dg/other/

I totally botched up this sve test file in 259437.
It needs C++, so move it to g++.dg/other and make it a .C file.
Also adds the target guards to prevent it from running on non-aarch64 targets.

Tested that it passes on aarch64-none-elf and doesn't get run on arm-none-eabi.

Committing to trunk as obvious.

PR testsuite/85483
* gcc.target/aarch64/sve/vcond_1.c: Move to...
* g++.dg/other/sve_vcond_1.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/vcond_1_run.c: Move to...
* g++.dg/other/sve_vcond_1_run.C: ... Here.  Change include file name.

Added:
trunk/gcc/testsuite/g++.dg/other/sve_vcond_1.C
trunk/gcc/testsuite/g++.dg/other/sve_vcond_1_run.C
Removed:
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1_run.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/85483] Many failures on test gcc.target/aarch64/sve/vcond_1.c

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85483

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|tree-optimization   |testsuite

[Bug tree-optimization/85483] Many failures on test gcc.target/aarch64/sve/vcond_1.c

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85483

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-20
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
That would be due to r259437.
vcond_1.c needs to be a C++ test rather than a C one.
It should be moved into g++.dg/other/

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85437

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c/85361] Variable length array allowed in c89/90

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361

--- Comment #3 from joseph at codesourcery dot com  ---
See the documentation of -std=, regarding base standards.

# The compiler can accept several base standards, such as @samp{c90} or
# @samp{c++98}, and GNU dialects of those standards, such as
# @samp{gnu90} or @samp{gnu++98}.  When a base standard is specified, the
# compiler accepts all programs following that standard plus those
# using GNU extensions that do not contradict it.  For example,
# @option{-std=c90} turns off certain features of GCC that are
# incompatible with ISO C90, such as the @code{asm} and @code{typeof}
# keywords, but not other GNU extensions that do not have a meaning in
# ISO C90, such as omitting the middle term of a @code{?:}
# expression. On the other hand, when a GNU dialect of a standard is
# specified, all features supported by the compiler are enabled, even when
# those features change the meaning of the base standard.  As a result, some
# strict-conforming programs may be rejected.  The particular standard
# is used by @option{-Wpedantic} to identify which features are GNU
# extensions given that version of the standard. For example
# @option{-std=gnu90 -Wpedantic} warns about C++ style @samp{//}
# comments, while @option{-std=gnu99 -Wpedantic} does not.

[Bug tree-optimization/85484] New: missing -Wstringop-overflow for strcpy with a string of non-const length

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85484

Bug ID: 85484
   Summary: missing -Wstringop-overflow for strcpy with a string
of non-const length
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The buffer overflow reported in bug 85476 can be reduced to the test case
below.The overflow is quite obvious and should be easy to detect at
compile-time via the -Wstringop-overflow warning yet GCC does not detect it,
either with or without -D_FORTIFY_SOURCE.  That's because __builtin_object_size
that -Wstringop-overflow relies on only deals with constant sizes.  But the
non-constant string length and allocation size are both readily available in
the tree-ssa-strlen pass and so the bug can easily be detected there.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic -fdump-tree-strlen=/dev/stdout
x.c
void f (char*);

void g (const char *s)
{
  unsigned n = __builtin_strlen (s);
  char *d = __builtin_alloca (n);   // off-by-one error (should be n + 1)
  __builtin_strcpy (d, s);  // missing -Wstringop-overflow
  f (d);
}

void h (const char *s)
{
  unsigned n = __builtin_strlen (s);
  char *d = __builtin_alloca (n);
  __builtin___strcpy_chk (d, s, __builtin_object_size (d, 1));
  f (d);
}


;; Function g (g, funcdef_no=0, decl_uid=1960, cgraph_uid=0, symbol_order=0)

g (const char * s)
{
  char * d;
  long unsigned int _1;
  long unsigned int _8;
  long unsigned int _10;

   [local count: 1073741825]:
  _1 = __builtin_strlen (s_3(D));
  _8 = _1 & 4294967295;
  d_5 = __builtin_alloca (_8);
  _10 = _1 + 1;
  __builtin_memcpy (d_5, s_3(D), _10);
  f (d_5);
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1965, cgraph_uid=1, symbol_order=1)

h (const char * s)
{
  char * d;
  long unsigned int _1;
  long unsigned int _2;
  long unsigned int _9;

   [local count: 1073741825]:
  _1 = __builtin_strlen (s_4(D));
  _9 = _1 & 4294967295;
  d_6 = __builtin_alloca (_9);
  _2 = _1 + 1;
  __builtin_memcpy (d_6, s_4(D), _2);
  f (d_6);
  return;

}

[Bug tree-optimization/85483] New: Many failures on test gcc.target/aarch64/sve/vcond_1.c

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85483

Bug ID: 85483
   Summary: Many failures on test gcc.target/aarch64/sve/vcond_1.c
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

I am seeing a bunch of failures in the gcc.target/aarch64/sve/vcond_1.c
test on aarch64.  You can see them on the test results list at:

https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01710.html

They seem to have showed up in the last 24 hours, but I am not sure 
exactly what patch caused them.

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[carll at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402

Carl Love  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||carll at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #14 from Carl Love  ---
Marking this issue fixed, resolved, see comment 13.

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[carll at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83402

--- Comment #13 from Carl Love  ---
Author: carll
Date: Fri Apr 20 15:18:24 2018
New Revision: 259524

URL: https://gcc.gnu.org/viewcvs?rev=259524&root=gcc&view=rev
Log:

gcc/ChangeLog:

2018-04-20  Carl Love  

PR target/83402
* config/rs6000/rs6000-c.c (rs6000_gimple_fold_builtin): Add
size check for arg0.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug target/85445] [nvptx, openacc] Calls to worker and vector routine broken

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85445

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Tom de Vries  ---
Patch with test-case committed, marking resolved-fixed.

[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com,   |
   |vegard.nossum at gmail dot com |
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #4 from Paolo Carlini  ---
Mine.

[Bug target/85445] [nvptx, openacc] Calls to worker and vector routine broken

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85445

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Fri Apr 20 13:46:07 2018
New Revision: 259523

URL: https://gcc.gnu.org/viewcvs?rev=259523&root=gcc&view=rev
Log:
[nvptx] Fix calls to vector and worker routines

2018-04-20  Nathan Sidwell  
Tom de Vries  

PR target/85445
* config/nvptx/nvptx.c (nvptx_emit_forking, nvptx_emit_joining):
Emit insns for calls too.
(nvptx_find_par): Always look for worker-level predecessor insn.
(nvptx_propagate): Add is_call parm, return bool.  Copy frame for
calls.
(nvptx_vpropagate, nvptx_wpropagate): Adjust.
(nvptx_process_pars): Propagate frames for calls.

* testsuite/libgomp.oacc-c++/ref-1.C: New.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c++/ref-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/libgomp/ChangeLog

[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85436

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Peter Bergner  ---
Fixed in GCC 7.

[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85469, which changed state.

Bug 85469 Summary: -mibt is unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/85469] -mibt is unused

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 8.

[Bug target/85469] -mibt is unused

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Apr 20 13:30:13 2018
New Revision: 259522

URL: https://gcc.gnu.org/viewcvs?rev=259522&root=gcc&view=rev
Log:
Define __CET__ for -fcf-protection and remove -mibt

With revision 259496:

commit b1384095a7c1d06a44b70853372ebe037b2f7867
Author: hjl 
Date:   Thu Apr 19 15:15:04 2018 +

x86: Enable -fcf-protection with multi-byte NOPs

-mibt does nothing and can be removed.  Define __CET__ to indicate level
protection with -fcf-protection:

(__CET__ & 1) != 0: -fcf-protection=branch or -fcf-protection=full
(__CET__ & 2) != 0: -fcf-protection=return or -fcf-protection=full

gcc/

PR target/85469
* common/config/i386/i386-common.c (OPTION_MASK_ISA_IBT_SET):
Removed.
(OPTION_MASK_ISA_IBT_UNSET): Likewise.
(ix86_handle_option): Don't handle OPT_mibt.
* config/i386/cet.h: Check __CET__ instead of __IBT__ and
__SHSTK__.
* config/i386/driver-i386.c (host_detect_local_cpu): Remove
has_ibt and ibt.
* config/i386/i386-c.c (ix86_target_macros_internal): Don't
check OPTION_MASK_ISA_IBT nor flag_cf_protection.
(ix86_target_macros): Define __CET__ with flag_cf_protection
for -fcf-protection.
* config/i386/i386.c (isa2_opts): Remove -mibt.
* config/i386/i386.h (TARGET_IBT): Removed.
(TARGET_IBT_P): Likewise.
(ix86_valid_target_attribute_inner_p): Don't check OPT_mibt.
* config/i386/i386.md (nop_endbr): Don't check TARGET_IBT.
* config/i386/i386.opt (mcet): Update help message.
(mshstk): Likewise.
(mibt): Removed.
* doc/invoke.texi: Remove -mibt.  Document __CET__.  Document
-mcet as an alias for -mshstk.

gcc/testsuite/

PR target/85469
* gcc.target/i386/pr85044.c (dg-options): Remove -mibt.
* gcc.target/i386/sse-26.c (dg-options): Remove -mno-ibt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c
trunk/gcc/config/i386/cet.h
trunk/gcc/config/i386/driver-i386.c
trunk/gcc/config/i386/i386-c.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/i386.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr85044.c
trunk/gcc/testsuite/gcc.target/i386/sse-26.c

[Bug objc/85476] ASAN error in finish_class ../../gcc/objc/objc-act.c:8006

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85476

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Fixed on trunk.

[Bug ipa/85449] [8 Regression] Wrong specialization is called in self recursive functions after r259319

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85449

--- Comment #13 from Tamar Christina  ---
Thanks Martin!

[Bug objc/85476] ASAN error in finish_class ../../gcc/objc/objc-act.c:8006

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85476

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Fri Apr 20 12:55:36 2018
New Revision: 259521

URL: https://gcc.gnu.org/viewcvs?rev=259521&root=gcc&view=rev
Log:
Do not overflow string buffer (PR objc/85476).

2018-04-20  Martin Liska  

PR objc/85476
* objc-act.c (finish_class): Do not overflow string buffer.

Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c

[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85436

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Fri Apr 20 12:19:10 2018
New Revision: 259520

URL: https://gcc.gnu.org/viewcvs?rev=259520&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2018-03-09  Peter Bergner  

PR target/83969
* config/rs6000/rs6000.c (rs6000_offsettable_memref_p): New prototype.
Add strict argument and use it.
(rs6000_split_multireg_move): Update for new strict argument.
(mem_operand_gpr): Disallow all non-offsettable addresses.
* config/rs6000/rs6000.md (*movdi_internal64): Use YZ constraint.

gcc/testsuite/
PR target/85436
* go.dg/pr85436.go: New test.

Backport from mainline
2018-03-09  Peter Bergner  

PR target/83969
* gcc.target/powerpc/pr83969.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83969.c
branches/gcc-7-branch/gcc/testsuite/go.dg/pr85436.go
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969

--- Comment #15 from Peter Bergner  ---
Author: bergner
Date: Fri Apr 20 12:19:10 2018
New Revision: 259520

URL: https://gcc.gnu.org/viewcvs?rev=259520&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2018-03-09  Peter Bergner  

PR target/83969
* config/rs6000/rs6000.c (rs6000_offsettable_memref_p): New prototype.
Add strict argument and use it.
(rs6000_split_multireg_move): Update for new strict argument.
(mem_operand_gpr): Disallow all non-offsettable addresses.
* config/rs6000/rs6000.md (*movdi_internal64): Use YZ constraint.

gcc/testsuite/
PR target/85436
* go.dg/pr85436.go: New test.

Backport from mainline
2018-03-09  Peter Bergner  

PR target/83969
* gcc.target/powerpc/pr83969.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83969.c
branches/gcc-7-branch/gcc/testsuite/go.dg/pr85436.go
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/85445] [nvptx, openacc] Calls to worker and vector routine broken

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85445

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> The initialization of the stack is done in thread W0V0, but the stack is
> read in  WAVA mode, so it's reading uninitialized stack memory in all but
> the W0V0 thread.

r239736 fixes this by propating the stack frame from W0V0 to WAVO:
...
$ diff -u bad.s ok.s 
--- bad.s   2018-04-20 09:36:51.122581511 +0200
+++ ok.s2018-04-20 09:53:01.971786471 +0200
@@ -344,28 +344,66 @@
.reg.u32 %r25;
.reg.u64 %r26;
.reg.u32 %r28;
-   .reg.pred %r30;
-   .reg.pred %r31;
+   .reg.u64 %r30;
+   .reg.u64 %r31;
+   .reg.u64 %r32;
+   .reg.u32 %r33;
+   .reg.pred %r34;
+   .reg.u64 %r35;
+   .reg.u64 %r36;
+   .reg.u64 %r37;
+   .reg.u64 %r38;
+   .reg.u32 %r39;
+   .reg.pred %r40;
+   .reg.u64 %r41;
+   .reg.pred %r42;
+   .reg.pred %r43;
{
.reg.u32%y;
mov.u32 %y, %tid.y;
-   setp.ne.u32 %r30, %y, 0;
+   setp.ne.u32 %r42, %y, 0;
}
{
.reg.u32%x;
mov.u32 %x, %tid.x;
-   setp.ne.u32 %r31, %x, 0;
+   setp.ne.u32 %r43, %x, 0;
}
-   @%r30   bra.uni $L30;
-   @%r31   bra $L31;
+   @%r42   bra.uni $L32;
+   @%r43   bra $L33;
mov.u64 %r24, %ar0;
mov.u32 %r25, 65536;
st.u32  [%frame], %r25;
mov.u32 %r28, 32;
ld.u64  %r26, [%r24];
+   // fork 14;
+   cvta.shared.u64 %r36, __worker_bcast;
+   mov.u64 %r38, %frame;
+   mov.u32 %r39, 2;
+   add.u64 %r41, %r36, 0;
 $L31:
-$L30:
+   add.u32 %r39, %r39, -1;
+   ld.u64  %r37, [%r38];
+   st.u64  [%r41], %r37;
+   add.u64 %r41, %r41, 8;
+   setp.ne.u32 %r40, %r39, 0;
+   add.u64 %r38, %r38, 8;
+   @%r40   bra.uni $L31;
+$L33:
+$L32:
+   bar.sync0;
// forked 14;
+   cvta.shared.u64 %r30, __worker_bcast;
+   mov.u64 %r32, %frame;
+   mov.u32 %r33, 2;
+   add.u64 %r35, %r30, 0;
+$L30:
+   add.u32 %r33, %r33, -1;
+   ld.u64  %r31, [%r35];
+   add.u64 %r35, %r35, 8;
+   st.u64  [%r32], %r31;
+   setp.ne.u32 %r34, %r33, 0;
+   add.u64 %r32, %r32, 8;
+   @%r34   bra.uni $L30;
{
.param.u64 %out_arg1;
st.param.u64 [%out_arg1], %r26;
@@ -377,6 +415,8 @@
st.param.u64 [%out_arg4], %frame;
call _Z6WorkerPiiiRKi, (%out_arg1, %out_arg2, %out_arg3,
%out_arg4);
}
+   // joining 14;
+   bar.sync1;
// join 14;
ret;
 }
...

[Bug target/85445] [nvptx, openacc] Calls to worker and vector routine broken

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85445

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> og7 test-case ref-1.C fails in execution when run with trunk:

At -O2, due to the call to routine Worker. The Vector routine is inlined, due
to missing noinline,noclone attributes.

> #pragma acc routine worker
> void Worker (int *ptr, int m, int n, const int &inc)
> {
>   #pragma acc loop worker
>   for (unsigned ix = 0; ix < m; ix++)
> Vector(ptr + ix * n, n, inc);
> }
> 

> int main ()
> {

> #pragma acc parallel copy(ary)
>   {
> Worker (&ary[0][0], m, n, 1<<16);
>   }

The inc parameter is a reference parameter, so the argument 1<<16 (65536) is
saved on stack:
...
mov.u32 %r25, 65536;
st.u32  [%frame], %r25; 
...

and the address is passed as argument:
...
.param.u64 %out_arg4;   
st.param.u64 [%out_arg4], %frame;   
call _Z6WorkerPiiiRKi, (%out_arg1, %out_arg2, %out_arg3,
%out_arg4);   
...

The stack is declared with .local:
...
.local .align 16 .b8 %frame_ar[16]; 
.reg.u64 %frame;
cvta.local.u64 %frame, %frame_ar;   
...

which means:
...
Local memory, private to each thread.
...

The initialization of the stack is done in thread W0V0, but the stack is read
in  WAVA mode, so it's reading uninitialized stack memory in all but the W0V0
thread.

[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

[thomas.petazz...@free-electrons.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401

--- Comment #6 from Thomas Petazzoni  ---
I see Eric Gallager added bug 68538 in the "See also" section. However, I don't
see how they can be related: 68538 has been fixed, and the fix was only in
CRIS-specific files.

This bug however is only about Microblaze, so I don't see how it can be related
to a bug that was fixed in CRIS-specific code.

[Bug c++/79736] [5 Regression] Please submit a full bug report: unable to create precompiled headers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79736

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.9.4, 6.1.0
   Target Milestone|--- |6.0
Summary|Please submit a full bug|[5 Regression] Please
   |report: unable to create|submit a full bug report:
   |precompiled headers |unable to create
   ||precompiled headers
  Known to fail||5.1.0, 5.5.0

--- Comment #3 from Jonathan Wakely  ---
I can reproduce this with gcc 5 but not gcc 6 or later. The preprocessed source
is 800kB even compressed, so I can't attach it.

The ICE started with r221641

PR c++/65498
* pt.c (get_mostly_instantiated_function_type): Just return the
type of the partially instantiated template in DECL_TI_TEMPLATE.

It was fixed by r227846

2015-09-17  Richard Biener

* cp-tree.h (note_decl_for_pch): Remove.
* class.c (build_clone): Do not call note_decl_for_pch.
* semantics.c (finish_member_declaration): Likewise.
(note_decl_for_pch): Remove.
* decl2.c (c_parse_final_cleanups): Mangle all globals before
writing the PCH.


Should we close it as FIXED?

[Bug tree-optimization/85478] ICE with single element vector

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 20 Apr 2018, krebbel at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478
> 
> --- Comment #4 from Andreas Krebbel  ---
> Indeed it does not appear to fail with a cross from x86. I've checked with
> r259518 on s390x as well as on x86. With an x86 cross no tree dump is 
> generated
> after 012t.ompexp and the generated assembler file does not contain any code.

I do see generated code for the explicitely instantiated operator.

sth like

void foo(ab *a, ab *b){ c::f *, ab *> (a,b); }
void bar(ab x) { ab<__float128> a(x); }

should instantiate both functions below explicitely but __float128
(taken from the demangling) doesn't do it and using 'long double'
ends up with a different mangling (and code).

That said, cross and native shouldn't differ and tracking down the
reason would be interesting.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #19 from Dennis Clarke  ---
status : RESOLVED FIXED <-- seems to not apply. 

For the sake of showing how there really is a problem here, we can 
neatly compile some trivial code and get bizarre results simply
because the platform would prefer to use the non-standard IBM long
double data type.  Any attempt to "add" two long doubles will result
in a call to _q_add which doesn't exist and ld fails. 

ppc64$ cat foo.c 

#define _XOPEN_SOURCE 600

#include 
#include 
#include 
#include 
#include 

int main ( int argc, char *argv[] ) {

int j;
struct utsname uname_data;
long double pi = 3.14159265358979323846264338327950288419716939937510L;
long double one = 1.0L;
long double two = 2.0L;

setlocale( LC_MESSAGES, "C" );
if ( uname( &uname_data ) < 0 ) {
fprintf ( stderr,
 "WARNING : Could not attain system uname data.\n" );
perror ( "uname" );
} else {
printf ("system name = %s\n", uname_data.sysname );
printf ("  node name = %s\n", uname_data.nodename );
printf ("release = %s\n", uname_data.release );
printf ("version = %s\n", uname_data.version );
printf ("machine = %s\n", uname_data.machine );
}
printf ("\n");

/* correct 128 bit big endian hex representation of pi is 
 *   0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */

printf("\naddr \"pi\" is %p\n", &pi );
printf("\ncontents : " );
for ( j=0; j -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ieeelongdouble -o foo foo.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
ppc64$ 
ppc64$ ./foo
system name = Linux
  node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64


addr "pi" is 0x7fffe4399650

contents : 40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 
 +2.07134954084936184770526779175270348787
 +3.1415926535897932384626433832795028841971 <- pi


addr "one" is 0x7fffe4399660

contents : 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 +1.937500


addr "two" is 0x7fffe4399670

contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 +2.00
ppc64$ 
ppc64$ 
ppc64$ /usr/local/gcc7/bin/gcc -m64 -std=iso9899:2011 \
> -Wfatal-errors -pedantic-errors -mcpu=970 -mfull-toc \
> -mregnames -mabi=ibmlongdouble -o foo foo.c
gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
ppc64$ ./foo
system name = Linux
  node name = nix
release = 4.16.2-genunix
version = #1 SMP Wed Apr 18 16:41:48 GMT 2018
machine = ppc64


addr "pi" is 0x75eef3e0

contents : 40 09 21 fb 54 44 2d 18 3c a1 a6 26 33 14 5c 06 
 +3.14159265358979323846264338327948122706
 +3.1415926535897932384626433832795028841971 <- pi


addr "one" is 0x75eef3f0

contents : 3f f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 +1.00


addr "two" is 0x75eef400

contents : 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 +2.00
ppc64$ 


Like you say "...it doesn't work at all unless you provide your own library."

So very true. 

Well this has been fun and I think a POWER9 server is needed to do 
any real work and certainly the hardware support will be fun.

[Bug tree-optimization/85478] ICE with single element vector

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #4 from Andreas Krebbel  ---
Indeed it does not appear to fail with a cross from x86. I've checked with
r259518 on s390x as well as on x86. With an x86 cross no tree dump is generated
after 012t.ompexp and the generated assembler file does not contain any code.

x86->s390x cross 012.ompexp:
...
;; Function c::f*, ab*> (_ZN1c1fIP2abIfEPS1_IeEEEiT_T0_,
funcdef_no=15, decl_uid
=2862, cgraph_uid=9, symbol_order=9)

c::f*, ab*> (struct ab * g, struct ab * h)
{
  struct ab * i;
  struct ab D.2925;

   :
  if (i == g)
goto ; [INV]
  else
goto ; [INV]

   :
  ab::ab (&D.2925, MEM[(const struct ab &)i]);
  *h = D.2925;
  h = h + 16;
  i = i + 16;
  goto ; [INV]

   :
  __builtin_unreachable ();

}



;; Function ab::ab (_ZN2abIeEC2ES_IfE, funcdef_no=6,
decl_uid=2666, cgraph_uid=2, symbol_order=2)

ab::ab (struct ab * const this, struct ab g)
{
  complex double D.2939;

   :
  MEM[(struct  &)this] = {CLOBBER};
  D.2939 = ab::m (&g);
  _1 = REALPART_EXPR ;
  _2 = IMAGPART_EXPR ;
  _3 = COMPLEX_EXPR <_1, _2>;
  this->n = _3;
  return;

}


s390x native 012.ompexp:

;; Function c::f*, ab*> (_ZN1c1fIP2abIfEPS1_IgEEEiT_T0_,
funcdef_no=15, decl_uid
=2896, cgraph_uid=9, symbol_order=9)

c::f*, ab*> (struct ab * g, struct ab * h)
{
  struct ab * i;
  struct ab D.2959;

   :
  if (i == g)
goto ; [INV]
  else
goto ; [INV]

   :
  ab::ab (&D.2959, MEM[(const struct ab &)i]);
  *h = D.2959;
  D.2959 = {CLOBBER};
  h = h + 32;
  i = i + 16;
  goto ; [INV]

   :
  __builtin_unreachable ();

}



;; Function ab::ab (_ZN2abIgEC2ES_IfE, funcdef_no=6,
decl_uid=2700, cgraph_uid=2, symbol_order=2)

ab::ab (struct ab * const this, struct ab g)
{
  complex double D.2973;

   :
  MEM[(struct  &)this] = {CLOBBER};
  D.2973 = ab::m (&g);
  _1 = REALPART_EXPR ;
  _2 = (long double) _1;
  _3 = IMAGPART_EXPR ;
  _4 = (long double) _3;
  _5 = COMPLEX_EXPR <_2, _4>;
  this->n = _5;
  return;

}

[Bug target/85482] unnecessary vmovaps/vmovapd/vmovdqa emitted

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85482

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-20
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug c++/85481] [8 Regression] ICE in maybe_explain_implicit_delete

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85481

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-checking

--- Comment #2 from Jakub Jelinek  ---
The ICE goes away also with -fno-checking.
1872  else if (flag_checking)
1873gcc_unreachable ();
Wonder if we just don't want else if (flag_checking && (errorcount + sorrycount
== 0))
instead.

[Bug c++/85481] [8 Regression] ICE in maybe_explain_implicit_delete

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85481

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-20
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE in  |[8 Regression] ICE in
   |maybe_explain_implicit_dele |maybe_explain_implicit_dele
   |te  |te
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r250994.

[Bug tree-optimization/85475] [8 Regression] Compile time hog w/ -O1 -fpeel-loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85475

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85475] [8 Regression] Compile time hog w/ -O1 -fpeel-loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85475

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Apr 20 10:31:23 2018
New Revision: 259519

URL: https://gcc.gnu.org/viewcvs?rev=259519&root=gcc&view=rev
Log:
2018-04-20  Richard Biener 

PR middle-end/85475
* match.pd ((X * CST) * Y -> (X * Y) * CST): Avoid exponential
complexity by forcing a single use of the multiply operand.

* gcc.dg/torture/pr85475.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85475.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #18 from Dennis Clarke  ---
We are saying the same thing here. 

Those same emulation routines exist elsewhere and are called _Qp_div,
_Qp_mul and _Qp_add on Solaris SPARC systems whereas those are 
implemented into other places with more or less the same names. 

Let's not go in circles here.  I see the issue and the old 970 is a
historical artifact.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #17 from Jakub Jelinek  ---
(In reply to Dennis Clarke from comment #16)
> It is annoying that the gcc compiler will produce the correct 
> assembly for both the IBM long double and the IEEE 754-2008 
> type 128-bit floating point.  One sort of works and the other

I have no idea what you mean by correct assembly for -mabi=ieeelongdouble.
If you try something as simple as
long double add (long double x, long double y) { return x + y; }
you'll see that it emits the SVR4 ABI calls like _q_add etc. for the software
emulation, but neither glibc nor gcc provides implementation for these.
So it doesn't work at all unless you provide your own library.  This isn't some
gap that libquadmath can cover, that library requires that {+,-,*,/} etc. work
and furthermore the type needs to be __float128, not long double.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #16 from Dennis Clarke  ---

Dear Jakub Jelinek : 

Exactly.

Yes, I think the libmpfr/libgmp seem to work perfectly here but
the real issue is that the old 970 and pre Power ISA v.2.03 spec
type hardware is a historical artifact like the old DEC Alpha. 

I see that in gcc 7.3.0 we do get share/info/libquadmath.info 
installed BUT in gcc 8 we do not.  This is good.

It is annoying that the gcc compiler will produce the correct 
assembly for both the IBM long double and the IEEE 754-2008 
type 128-bit floating point.  One sort of works and the other
does not at all.  A value for pi becomes 2.0713495408... etc.

The gcc manual page for "IBM RS/6000 and PowerPC Options" needs
a bit of a re-write to address the strange results one may get
from the use of "-mabi" ieeelongdouble or ibmlongdouble.  At
the very least the "warning" exists to let a user know that 
something is amiss here and strange results may occur.

Dennis Clarke

[Bug ipa/85449] [8 Regression] Wrong specialization is called in self recursive functions after r259319

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85449

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Jambor  ---
I forgot to put letters "PR" to the bug reference, anyway fixed with:

Author: jamborm
Date: Fri Apr 20 09:35:33 2018
New Revision: 259518

URL: https://gcc.gnu.org/viewcvs?rev=259518&root=gcc&view=rev
Log:
Fix IPA-CP test for self-feeding recursive dependency

2018-04-20  Martin Jambor  

ipa/85449
* ipa-cp.c (cgraph_edge_brings_value_p): Move check for self-feeding
recursion dependency to only apply to non-clones.

testsuite/
* gcc.dg/ipa/pr85449.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr85449.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85447

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Martin Jambor  ---
I forgot to put letters "PR" to the bug reference, anyway fixed with:

Author: jamborm
Date: Fri Apr 20 09:19:39 2018
New Revision: 259517

URL: https://gcc.gnu.org/viewcvs?rev=259517&root=gcc&view=rev
Log:
Check that clones of edges exist during IPA-CP

2018-04-20  Martin Jambor  

ipa/85447
* ipa-cp.c (create_specialized_node): Check that clones of
self-recursive edges exist during IPA-CP.

testsuite/
* g++.dg/ipa/pr85447.C: New file.
* gcc.dg/ipa/ipcp-self-recursion-1.c: Likewise.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr85447.C
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-self-recursion-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85478] ICE with single element vector

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #3 from Richard Biener  ---
Hmm, it doesn't seem to ICE for me (with a cross from x86_64-linux).  I
configured with --target s390x-linux-gnu

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

--- Comment #15 from Jakub Jelinek  ---
For libquadmath you need a working __float128 support.  On x86_64, i686 and
ia64 this is done through a slow software emulation in libgcc.  On powerpc*,
there is either a software emulation which requires VSX, or hardware
implementation which requires power9.  On s390 there is hardware
implementation, but long double is already quad, so you don't need libquadmath.
 For everything else, just use mpfr.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440

Dennis Clarke  changed:

   What|Removed |Added

  Known to work|8.0 |

--- Comment #14 from Dennis Clarke  ---
We are going in circles here. 

Neither libquadmath nor the required header exist nor function on the
powerpc64 target wherein the processor is NOT an IBM power type unit.

It is NOT known to work with gcc version 8 either as I have tested for
that and the answer is a clear no. 

This is NOT a power8 nor a power7 nor any version thereof. This is the
classic IBM PowerPC 970FX processor.  

This is big endian.

There is NOT an option for "VSX by default".

The real issue seems to lay down inside glibc, which I was looking at 
from the very beginning and I had already said the "non-IBM Power 
variations are simply not supported" and in glibc 2.26 we see : 

  On ia64, powerpc64le, x86-32, and x86-64, the math library now implements
  128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE
  754-2008) and ISO/IEC TS 18661-3:2015.  Contributed by Paul E. Murphy,
  Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers.

  To compile programs that use this feature, the compiler must support
  128-bit floating point with the type name _Float128 (as defined by TS
  18661-3) or __float128 (the nonstandard name used by GCC for C++, and for
  C prior to version 7).  _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__
  must be defined to make the new interfaces visible.

  The new functions and macros correspond to those present for other
  floating-point types (except for a few obsolescent interfaces not
  supported for the new type), with F128 or f128 suffixes; for example,
  strtof128, HUGE_VAL_F128 and cosf128.  Following TS 18661-3, there are no
  printf or scanf formats for the new type; the strfromf128 and strtof128
  interfaces should be used instead.

This was soon followed by 2.27 wherein : 

  On platforms where long double has the IEEE binary128 format (aarch64,
  alpha, mips64, riscv, s390 and sparc), the math library now implements
  _Float128 interfaces for that type, as defined by ISO/IEC TS 18661-3:2015.
  These are the same interfaces added in version 2.26 for some platforms where
  this format is supported but is not the format of long double.

However the gcc version 8 20180415 will compile C source and produce assembly
that clearly uses the 128-bit IEEE 754-2008 format for floating point data
however the options for -mfloat128 and -mfloat128-hardware clearly won't work
here.  The manual page is slightly misleading for "RS/6000 and PowerPC" options
as really there needs to exist a page for "IBM Power" options. 

The options for abi ibmlongdouble and ieeelongdouble both work as expected and
I
have already shown that along with the output assembly wherein we do actually
get both 128-bit datatypes : 


gcc: warning: using IBM extended precision long double
cc1: warning: using IBM extended precision long double
.quad   0x400921fb54442d18,0x3ca1a62633145c06

$ /usr/local/gcc7/bin/gcc -m64 -g -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec
-mfull-toc -mregnames -mabi=ieeelongdouble -S -o ld.s ld.c ; grep "quad" ld.s |
grep "0x"
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
.quad   0x4000921fb54442d1,0x8469898cc51701b8

Regardless how you slice it here and want to say "works in ver 8" it simply
does
not and I have a powerpc 64-bit big-endian machine right here that bootstraps 
both version 7.3.0 and the available ver 8 test tarball just fine.  Neither can
do anything with libquadmath on this architecture as it is clearly not one of
the IBM Power variants under Power ISA v.2.07 spec.  Perhaps there needs to be
a new manual page for "IBM RS/6000 and PowerPC Options" because really there
exists the "IBM Power" systems and then the older "IBM RS/6000 and PowerPC
Options".
That may also cover the whole SoC type chips that we saw so many of from
FreeScale
and Motorola at one point. 

Someone, whomever it is, stop flipping this as "known to work on 8" where that
just isn't true.

[Bug target/85482] unnecessary vmovaps/vmovapd/vmovdqa emitted

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85482

Matthias Kretz  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*

--- Comment #1 from Matthias Kretz  ---
related to PR85480

[Bug target/85482] New: unnecessary vmovaps/vmovapd/vmovdqa emitted

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85482

Bug ID: 85482
   Summary: unnecessary vmovaps/vmovapd/vmovdqa emitted
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (cf. https://godbolt.org/g/QkJYSK):
#include 

__m256 zero_extend1(__m128 a) {
return _mm256_insertf128_ps(__m256(), a, 0);
}
__m256d zero_extend1(__m128d a) {
return _mm256_insertf128_pd(__m256d(), a, 0);
}
__m256i zero_extend1(__m128i a) {
return _mm256_insertf128_si256(__m256i(), a, 0);
}

__m512 zero_extend2(__m128 a) {
return _mm512_insertf32x4(__m512(), a, 0);
}
__m512d zero_extend2(__m128d a) {
return _mm512_insertf64x2(__m512d(), a, 0);
}
__m512i zero_extend2(__m128i a) {
return _mm512_inserti32x4(__m512i(), a, 0);
}

__m512 zero_extend3(__m256 a) {
return _mm512_insertf32x8(__m512(), a, 0);
}
__m512d zero_extend3(__m256d a) {
return _mm512_insertf64x4(__m512d(), a, 0);
}
__m512i zero_extend3(__m256i a) {
return _mm512_inserti64x4(__m512i(), a, 0);
}

template  T blackhole;

void test(void *mem) {
blackhole<__m256 > = zero_extend1(_mm_load_ps((float *)mem));
blackhole<__m256d> = zero_extend1(_mm_load_pd((double *)mem));
blackhole<__m256i> = zero_extend1(_mm_load_si128((__m128i *)mem));
blackhole<__m512 > = zero_extend2(_mm_load_ps((float *)mem));
blackhole<__m512d> = zero_extend2(_mm_load_pd((double *)mem));
blackhole<__m512i> = zero_extend2(_mm_load_si128((__m128i *)mem));
blackhole<__m512 > = zero_extend3(_mm256_load_ps((float *)mem));
blackhole<__m512d> = zero_extend3(_mm256_load_pd((double *)mem));
blackhole<__m512i> = zero_extend3(_mm256_load_si256((__m256i *)mem));
}

Between every load and store instruction in the `test` function, the
vmov(aps|apd|dqa) is superfluous. The preceding load instruction already zeroes
the high bits. Instead of the load instruction, there could also be a different
instructions, or instruction sequences, that already guarantee the high bits to
be zero.

[Bug tree-optimization/85478] ICE with single element vector

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #2 from Andreas Krebbel  ---
I've opened another bugzilla for a probably unrelated problem triggered by a
testcase reduce from the same source file:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85481

[Bug c++/85481] New: ICE in maybe_explain_implicit_delete

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85481

Bug ID: 85481
   Summary: ICE in maybe_explain_implicit_delete
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43998&action=edit
Autoreduced testcase

cc1plus t.cc

 } class b {
t.cc:2:1: error: expected ‘,’ or ‘...’ before ‘}’ token
  )
 ^
t.cc:2:2: error: expected ‘;’ after class definition
  ^
t.cc:3:14: error: expected ‘;’ at end of member declaration
t.cc:4:2: error: expected ‘;’ after class definition
 } class B {   virtual ~B(;
  b d
   
^
   
 ;
t.cc:5:2: error: expected ‘;’ after class definition
 } template class : B {
  ^
  ;
t.cc:5:22: error: expected ‘}’ at end of input
 } template class : B {
  ^
t.cc:5:18: error: use of deleted function ‘b::~b()’
 } template class : B {
  ^
t.cc:3:7: internal compiler error: in maybe_explain_implicit_delete, at
cp/method.c:1873
   a c ~b() = default
   ^
0x12e6821 maybe_explain_implicit_delete(tree_node*)
/home/andreas/build/../gcc/gcc/cp/method.c:1873
0x12888b1 mark_used(tree_node*, int)
/home/andreas/build/../gcc/gcc/cp/decl2.c:5255
0x11ad759 build_over_call
/home/andreas/build/../gcc/gcc/cp/call.c:7736
0x11b221b build_new_method_call_1
/home/andreas/build/../gcc/gcc/cp/call.c:9378
0x11b221b build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/andreas/build/../gcc/gcc/cp/call.c:9453
0x12da887 locate_fn_flags
/home/andreas/build/../gcc/gcc/cp/method.c:1024
0x12ddee3 walk_field_subobs
/home/andreas/build/../gcc/gcc/cp/method.c:1439
0x12dedab synthesized_method_walk
/home/andreas/build/../gcc/gcc/cp/method.c:1741
0x12e38f3 get_defaulted_eh_spec(tree_node*, int)
/home/andreas/build/../gcc/gcc/cp/method.c:1775
0x13c5105 maybe_instantiate_noexcept(tree_node*, int)
/home/andreas/build/../gcc/gcc/cp/pt.c:23256
0x13d9de5 check_final_overrider
/home/andreas/build/../gcc/gcc/cp/search.c:1935
0x13d9de5 look_for_overrides_r
/home/andreas/build/../gcc/gcc/cp/search.c:2089
0x13d9de5 look_for_overrides(tree_node*, tree_node*)
/home/andreas/build/../gcc/gcc/cp/search.c:2034
0x11d6b8d check_for_override(tree_node*, tree_node*)
/home/andreas/build/../gcc/gcc/cp/class.c:2774
0x12e1a13 lazily_declare_fn(special_function_kind, tree_node*)
/home/andreas/build/../gcc/gcc/cp/method.c:2404
0x11c9125 dfs_declare_virt_assop_and_dtor
/home/andreas/build/../gcc/gcc/cp/class.c:3011
0x13d4d57 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*),
tree_node* (*)(tree_node*, void*), void*)
/home/andreas/build/../gcc/gcc/cp/search.c:1410
0x13d4ded dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*),
tree_node* (*)(tree_node*, void*), void*)
/home/andreas/build/../gcc/gcc/cp/search.c:1422
0x11ea4c5 declare_virt_assop_and_dtor
/home/andreas/build/../gcc/gcc/cp/class.c:3030
0x11ea4c5 add_implicitly_declared_members
/home/andreas/build/../gcc/gcc/cp/class.c:3170

[Bug c++/85479] ice in inc_refcount_use

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85479

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
just fixed

*** This bug has been marked as a duplicate of bug 85462 ***

[Bug target/85480] zero extension from xmm to zmm via _mm512_insert???x? not optimized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85480

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think I noted it elsewhere already (in vectorizer context), the patterns are
somewhat incomplete.

[Bug c++/85462] [8 Regression] internal compiler error: in inc_refcount_use, at cp/pt.c:8955

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85462

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from Richard Biener  ---
*** Bug 85479 has been marked as a duplicate of this bug. ***

[Bug ipa/85449] [8 Regression] Wrong specialization is called in self recursive functions after r259319

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85449

--- Comment #11 from Martin Jambor  ---
I have posted the following fix to the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00996.html

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85447

--- Comment #9 from Martin Jambor  ---
Eventually, we have decided to go for a more limited fix which I have posted to
the mailing list: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00995.html

[Bug target/85480] New: zero extension from xmm to zmm via _mm512_insert???x? not optimized

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85480

Bug ID: 85480
   Summary: zero extension from xmm to zmm via _mm512_insert???x?
not optimized
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (cf. https://godbolt.org/g/p4Kt8X):

#include 
__m512 zero_extend2(__m128 a) {
return _mm512_insertf32x4(__m512(), a, 0);
}
__m512d zero_extend2(__m128d a) {
return _mm512_insertf64x2(__m512d(), a, 0);
}
__m512i zero_extend2(__m128i a) {
return _mm512_inserti32x4(__m512i(), a, 0);
}

These 3 functions should compile to `vmovaps %xmm0, %xmm0`, `vmovapd %xmm0,
%xmm0`, and `vmovdqa %xmm0, %xmm0`, respectively.

GCC detects the optimization for the xmm->ymm and ymm->zmm cases already. It's
only missing for the xmm->zmm case.

[Bug c++/85479] New: ice in inc_refcount_use

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85479

Bug ID: 85479
   Summary: ice in inc_refcount_use
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 43997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43997&action=edit
gzipped C++ source code

The attached C++ code, when compiled by recent trunk gcc, does this:

In file included from array_real.cpp:28:
array_tlp.hpp: In instantiation of ‘void ArrayOperator() [with K = double; Z =
l
ong int]’:
array_real.cpp:44:32:   required from here
array_tlp.hpp:1703:27: internal compiler error: in inc_refcount_use, at
cp/pt.c:
8955
0x63784e inc_refcount_use
../../trunk/gcc/cp/pt.c:8955
0x63784e set_refcount_ptr
../../trunk/gcc/cp/pt.c:8994
0x998992 push_tinst_level_loc
../../trunk/gcc/cp/pt.c:10152

The new bug seems to exist between revision 259439 and 259515.

I will have my usual go at reducing the code.

[Bug tree-optimization/85478] ICE with single element vector

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

--- Comment #1 from Andreas Krebbel  ---
The testcases ICEs since r253196:

S/390: Set the preferred mode for float vectors

gcc/ChangeLog:

2017-09-26  Andreas Krebbel  

* config/s390/s390.c (s390_preferred_simd_mode): Return V4SFmode
for SFmode.


with:

during RTL pass: reload
t2.cc: In member function ‘dealii::FullMatrix&
dealii::FullMatrix::operator=(const dealii::FullMatrix&) [with
number2 = std::complex; number = std::complex]’:
t2.cc:199:3: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

   }
   ^
0x185f553 lra_constraints(bool)
/home/andreas/gcc/gcc/lra-constraints.c:4756
0x1845459 lra(_IO_FILE*)
/home/andreas/gcc/gcc/lra.c:2390
0x17f260b do_reload
/home/andreas/gcc/gcc/ira.c:5440
0x17f260b execute
/home/andreas/gcc/gcc/ira.c:5624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



With the poly-int patches the ICE is triggered during vectorization already
probably papering over the original ICE.

With the patch posted here the vectorization will not continue and does not
appear to end up in that situation anymore:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00758.html

[Bug sanitizer/84761] AddressSanitizer is not compatible with glibc 2.27 on x86

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761

Martin Liška  changed:

   What|Removed |Added

 CC||belous.vs at yandex dot ru

--- Comment #11 from Martin Liška  ---
*** Bug 85477 has been marked as a duplicate of this bug. ***

[Bug sanitizer/85477] IO_old_cookie_seek is called instead of _IO_cookie_seek when compiled with -fsanitize=address

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85477

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Liška  ---
It's dup. With the fix I see:

$ gcc -m32  -fsanitize=undefined,address pr85477.c && ./a.out 
ASAN:DEADLYSIGNAL
=
==24720==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fe82f0 (pc
0xf7fe8304 bp 0xf7b5c320 sp 0xcdec T16777215)
==24720==The signal is caused by a WRITE memory access.
#0 0xf7fe8303 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x12303)
#1 0xf7acce69  (/usr/lib/libasan.so.4+0x104e69)
#2 0xf7ab8a65  (/usr/lib/libasan.so.4+0xf0a65)
#3 0xf7fe5c7a in _dl_init (/lib/ld-linux.so.2+0xfc7a)
#4 0xf7fd6cb9  (/lib/ld-linux.so.2+0xcb9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x12303) in
_dl_get_tls_static_info
==24720==ABORTING

*** This bug has been marked as a duplicate of bug 84761 ***

[Bug tree-optimization/85478] New: ICE with single element vector

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85478

Bug ID: 85478
   Summary: ICE with single element vector
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43996&action=edit
Autoreduced testcase

Compiling the attached testcase triggers an ICE

cc1plus -march=arch12 -O3 -fpermissive t.cc

Performing interprocedural optimizations   
 <*free_lang_data>   

  
 Assembling functions:
  s& s::operator=(const s&) [with t =
ab; ae = ab]during GIMPLE pass: vect

t2.cc: In member function ‘s& s::operator=(const s&) [with t =
ab; ae = ab]’:
t2.cc:39:8: internal compiler error: in exact_div, at poly-int.h:2139   
 s &s::operator=(const s &g) {  
^
0x21e8941 poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, int>(poly_int_pod<1u, unsigned long> const&, int)
/home/andreas/build/../gcc/gcc/poly-int.h:2139  
0x21e8941 vect_grouped_store_supported(tree_node*, unsigned long)   
/home/andreas/build/../gcc/gcc/tree-vect-data-refs.c:5150   
0x1ce5115 vect_analyze_loop_2  
/home/andreas/build/../gcc/gcc/tree-vect-loop.c:2495
0x1ce5115 vect_analyze_loop(loop*, _loop_vec_info*) 
/home/andreas/build/../gcc/gcc/tree-vect-loop.c:2621
0x1d03e13 vectorize_loops()
/home/andreas/build/../gcc/gcc/tree-vectorizer.c:664

[Bug tree-optimization/85406] Unnecessary blend when vectorizing short-cutted calculations

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85406

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|WAITING |NEW
 Blocks||53947

--- Comment #5 from Richard Biener  ---
I think it's too much asked from GCC to prove that if a == 255 the computation
in the else path would result in x.  The simplest fix would be to remove the
conditional in the source.

It's true that GCC doesn't evaluate costs of the vectorization properly
as it looks at the if-converted copy when calculating the cost of the
scalar loop.  OTOH any estimate on how often the shortcut triggers
compared to the computation might be off and a conservative estimate may
cause us to not vectorize and thus slow down the code.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c++/56326] g++.dg/gomp/tls-wrap4.C and g++.dg/tls/thread_local-wrap4.C FAIL on Solaris 9/x86

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56326

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Rainer Orth  ---
Closing, Solaris 9 support is long gone.

[Bug target/58111] 32-bit gcc.target/i386/pr55342.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58111

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Rainer Orth  ---
Long fixed.

[Bug go/59453] log/syslog FAILs on Solaris 9

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59453

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Rainer Orth  ---
Closing, Solaris 9 support is long gone.

[Bug go/59452] net FAILs on Solaris 9

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59452

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Rainer Orth  ---
Closing, Solaris 9 support is long gone.

[Bug target/59664] avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Rainer Orth  ---
Closing, Solaris 9 support is long gone.