[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
I've copied the test-cases, and build r259123.

For libgomp.oacc-c/c.exp, we get:
...
$ cat libgomp.testsuite/libgomp.sum | grep ^FAIL:.*execution | grep -v /lib- |
sed 's/libgomp.oacc-c\/..\/libgomp.oacc-c-c++-common\///'
FAIL: avoid-offloading-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: broadcast-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: data-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: data-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: data-4.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: data-4.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: declare-3.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: declare-3.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: enter-data.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: enter-data.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: fp-dyn-arrays.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: fp-dyn-arrays.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: gang-private-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: gang-private-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
FAIL: inner-reduction.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: pr70828.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution
test
FAIL: pr70828.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution
test
FAIL: reduction-9.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
execution test
FAIL: reduction-9.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
execution test
...

[Bug target/85220] New: [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[vries at gcc dot gnu.org]

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

Bug ID: 85220
   Summary: [meta-bug, nvptx] Run trunk with og7 openacc testcases
and analyze execution failures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

OpenACC for nvptx development has been going on in the development branch
openacc-gcc-7-branch (og7 for short). [ And before that, in gomp-4_0-branch. ]

The test-cases in the og7 branch may uncover problems in trunk, for which no
upstream PR exists (f.i., in the case of broadcast-1.c, a patch attempting to
fix a problem was submitted for trunk, and then committed to og7, without
opening a PR, leaving the problem existing and untracked on trunk. I've just
filed PR85204 - "[nvptx] infinite loop generated" for that one).

We need to run the test-cases from og7 using trunk, and analyze the execution
failures.

[Bug c++/80290] [6/7/8 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #19 from Alexandre Oliva  ---
Mine

[Bug c++/84979] [6/7/8 Regression] ICE with auto as template parameter and -fconcepts

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Apr  5 04:26:36 2018
New Revision: 259124

URL: https://gcc.gnu.org/viewcvs?rev=259124=gcc=rev
Log:
[PR c++/84979] reject auto in explicit tmpl args for tmpl-fn

With concepts, we accept auto in explicit template arguments, but we
should only accept them for template classes.  Passing them to
template functions or variables is not allowed.  So, reject it, at
parse time if possible, at specialization time otherwise.


for  gcc/cp/ChangeLog

PR c++/84979
* pt.c (check_auto_in_tmpl_args): New.
(tsubst_qualified_id): Use it to reject template args
referencing auto for non-type templates.
* parser.c (cp_parser_template_id): Likewise.
* cp-tree.h (check_auto_in_tmpl_args): Declare.
* typeck2.c (build_functional_cast): Report correct location
for invalid use of auto.

for  gcc/testsuite/ChangeLog

PR c++/84979
* g++.dg/concepts/pr84979.C: New.
* g++.dg/concepts/pr84979-2.C: New.
* g++.dg/concepts/pr84979-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr84979-2.C
trunk/gcc/testsuite/g++.dg/concepts/pr84979-3.C
trunk/gcc/testsuite/g++.dg/concepts/pr84979.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 04:01:15 2018
New Revision: 259123

URL: https://gcc.gnu.org/viewcvs?rev=259123=gcc=rev
Log:
PR c++/85215 - ICE with copy-init from conversion.

* call.c (merge_conversion_sequences): Fix type of direct binding
sequence.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/elide3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug gcov-profile/85219] New: [GCOV] A "if(1) continue;" statement in a the else block of "if(0)" statement is wrongly marked as executed when surrounded by array delaration statement and break/contin

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85219
   Summary: [GCOV] A "if(1) continue;" statement in a the else
block of "if(0)" statement is wrongly marked as
executed when surrounded by array delaration statement
and break/continue statement in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)


$ cat small.c
void  main ()
{
int a = 0;
for (; a < 1; a++) {
int b[1];
if ( 1 )
;
else {
if (1)
continue;
break;
}
continue;
}
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:void  main ()
-:2:{
1:3:int a = 0;
2:4:for (; a < 1; a++) {
-:5:int b[1];
-:6:if ( 1 )
-:7:;
-:8:else {
-:9:if (1)
1:   10:continue;
-:   11:break;
-:   12:}
1:   13:continue;
-:   14:}
1:   15:}



**
Line #10 is wrongly marked as executed here. 
While remoing any of the statement in Line #11 or Line #13 or Line #5, the
result is correct. 
**

[Bug gcov-profile/85199] [GCOV] A cond-expr with a iterative variable in a for loop is marked as "-" in gcov

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
(In reply to Yibiao Yang from comment #0)
> $ gcc -v 
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-8
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
> 8-20170923-1ubuntu2)
> 
> $ cat small.c
> void main()
> {
> int b = 0;
> for(;
> b < 1;
> b++) {
> ;
> }
> }
> 
> $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
> File 'small.c'
> Lines executed:100.00% of 5
> Creating 'small.c.gcov'
> 
> -:0:Source:small.c
> -:0:Graph:small.gcno
> -:0:Data:small.gcda
> -:0:Runs:1
> -:0:Programs:1
> 1:1:void main()
> -:2:{
> 1:3:int b = 0;
> 2:4:for(;
> -:5:b < 1;
> 1:6:b++) {
> -:7:;
> -:8:}
> 1:9:}
> 
> Here, we can see that Line #4 is marked as executed twice and Line #5 "b <
> 1;" is marked as "-".
> 

I was wondering that this is the default behavior of gcov.

[Bug gcov-profile/85218] New: [GCOV] A return statement in the if(0) block is wrongly marked as executed when there is an array index and an {array declare statement} around it in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85218
   Summary: [GCOV] A return statement in the if(0) block is
wrongly marked as executed when there is an array
index and an {array declare statement} around it in
gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
int main()
{
int b[1] = {0};
b[0];
if (0)
return 0;
return 1;

{
int c[1];
}
}


$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat sall.c.gcov
File 'small.c'
Lines executed:100.00% of 4
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int main()
-:2:{
1:3:int b[1] = {0};
-:4:b[0];
-:5:if (0)
1:6:return 0;
1:7:return 1;
-:8:
-:9:{
-:   10:int c[1];
-:   11:}
-:   12:}


**
Line #6 is wrongly marked as executed. 

The result is correct while removing the following lines:
Line 9 and Line 11 (the braces) are removed
or
Line #4 is removed.

[Bug gcov-profile/85217] [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
$ gcc -v 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

In addition, the result is also correct when Line #5 is removed.

[Bug gcov-profile/85217] New: [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85217
   Summary: [GCOV] A no side effect statement between a break
statement and a continue statement will lead to
incorrect code coverage in gcov
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ cat small.c
int a=0;

void main() {
  for (;; a++) {
int c[1];
if (a) {
  break;
  a;
  continue;
}
continue;
  }
}


$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int a=0;
-:2:
2:3:void main() {
1:4:  for (;; a++) {
-:5:int c[1];
2:6:if (a) {
1:7:  break;
-:8:  a;
1:9:  continue;
-:   10:}
1:   11:continue;
-:   12:  }
1:   13:}

Line #9 is wrongly marked as executed. While Line #8 or Line #11 is removed,
the result is correct.

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
(In reply to Rainer Orth from comment #26)
> Author: ro
> Date: Thu Jun 30 10:02:45 2011
> New Revision: 175689
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=175689
> Log:
> 2011-06-28  Dominique d'Humieres  
>   Iain Sandoe  
> 
>   PR libobjc/36610
>   * objc.dg/torture/forward-1.m: Remove dg-xfail-run-if.
>   Only skip on 64-bit *-*-darwin8* && !objc2.
> 
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/objc.dg/torture/forward-1.m

Did this fix it?

[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Confirmed that g2() still contains the call to __builtin_abort()

[Bug c++/71218] Add a warning about "new T[integer-literal]"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Marc Glisse from comment #1)
> > Can you be more specific? Do you mean people should have written:
> > T tab[8];
> 
> Yes, exactly. I was fixing some code earlier today that used a dynamically
> allocated buffer of 8 chars and deleted it at the end of the function (but
> failed to do so on two early return paths). There was no reason it was done
> that way instead of using an automatic array, probably just someone who
> learnt to programme in Java and didn't know better.
> 
> > instead? What if 8 or sizeof(T) is large?
> 
> The case I looked at was char, it would probably be OK to only warn for
> scalar types, and for small array lengths (for some value of small).
> 
> > If your "..." includes possible
> > writes to p, or if p escapes and "..." may throw, I guess that cancels the
> > warning? At some point the issue becomes similar to optimizing malloc to a
> > stack allocation.
> 
> Part of the problem in the code I was fixing was that the "..." certainly
> could throw, and the delete never happened.
> 
> But maybe the escape analysis is too tricky.

Worth trying anyways; confirmed that it could be worthwhile to add this
warning.

[Bug tree-optimization/47316] devirtualize calls to virtual methods that are never further overriden

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=46043

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Jambor from comment #3)
> Actually, thanks for filing the bug.  Devirtualization and other
> optimizations (such as struct-reorg) based on type escape analysis are
> a debated issue and it is nice to know users have interest in it.

Another example of interest in escape analysis:
https://twitter.com/gnutools/status/978633915450712064

[Bug tree-optimization/52571] vectorizer changes alignment of common symbols

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=48127,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=49379,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52614

--- Comment #15 from Eric Gallager  ---
(In reply to m...@gcc.gnu.org from comment #14)
> Uncommoning things I think might well be slightly harder than trivial.  A
> ctor is allowed to dynamically load a shared library, that defines a symbol,
> maybe, conditional on the environment.  But with proper escape analysis,
> seems like one can figure it all out, just be careful with the edge cases.

What changes need to be made to the escape analysis to make it "proper"?

[Bug c++/71283] Inconsistent location for C++ warning options in the manual

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Martin Sebor brought this up on the mailing lists here:
https://gcc.gnu.org/ml/gcc/2018-04/msg00021.html

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
One possibility is bad luck and the branch happens to fall on an address that
conflicts with another branch.

[Bug c++/85209] [8 Regression] ICE with lambda and structured binding

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Broke with r251433.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #6 from Timothy Pearson  ---
Understood.  I'll update this report if we find a way to get the predictor
working optimally in this scenario.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #5 from David Edelsohn  ---
The issue is *why* the branch predictor is not predicting it correctly. It may
be that the details of the branch predictor are causing the prediction to
conflict with another branch, for example, nullifying the correct prediction.
One should not leap to the conclusion that the predictor is not initialized.

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #4 from Timothy Pearson  ---
(In reply to Andrew Pinski from comment #3)
> This is 100% the equivalent code.
> 
> jmp *(%r15) # opline.199_67->handler
> Does two things:
> loads a pointer from %r15 and then jumps to that pointer.
> 
> In PowerPC, you can only jump indirectly via the CTR or LR registers.
> 
> ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
> mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
> bctr
> 
> 
> Most likely what is happening is the indirect branch predictor is not
> predicting the branch correctly on the powerpc side while it is on the x86
> side.  This is a micro-architecture difference between the two chips and is
> unrelated to the ISA differences.

I'm forwarding this for analysis to see if there's anything we can do in
firmware to "fix" the branch predictor.  If not, is there a way to prime the
predictor in this scenario, or is this too specific to be added compiler-side?

[Bug target/85216] Performance issue with PHP on ppc64 systems

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Last reconfirmed|2018-04-05 00:00:00 |
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
This is 100% the equivalent code.

jmp *(%r15) # opline.199_67->handler
Does two things:
loads a pointer from %r15 and then jumps to that pointer.

In PowerPC, you can only jump indirectly via the CTR or LR registers.

ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
bctr


Most likely what is happening is the indirect branch predictor is not
predicting the branch correctly on the powerpc side while it is on the x86
side.  This is a micro-architecture difference between the two chips and is
unrelated to the ISA differences.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

--- Comment #2 from Timothy Pearson  ---
(In reply to David Edelsohn from comment #1)
> What two additional instructions?  x86 is a CISC architecture and Power is a
> RISC architecture.  x86 has an instruction that directly performs an
> indirect call through a pointer. Power must explicitly load the pointer and
> move it to the appropriate register to perform an indirect branch.
> 
> One can comment / questions that the *SEQUENCE* appears to require more time
> on Power than the equivalent sequence on x86. But directly comparing
> instructions and counting instructions in two different ISAs without context
> is not meaningful.

That is in fact what I am concerned with, the fact that the sequence is taking
longer than the equivalent sequence on x86.  I am aware that the two
instruction sequences accomplish the same goal, but for some reason the x86 one
is fast enough that it doesn't even show up in the perf output as a hot
instruction, while the ppc64 sequence stalls twice (two hot instructions), once
on the load and once on the register move.

[Bug target/85216] Performance issue with PHP on ppc64 systems

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-05
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
What two additional instructions?  x86 is a CISC architecture and Power is a
RISC architecture.  x86 has an instruction that directly performs an indirect
call through a pointer. Power must explicitly load the pointer and move it to
the appropriate register to perform an indirect branch.

One can comment / questions that the *SEQUENCE* appears to require more time on
Power than the equivalent sequence on x86. But directly comparing instructions
and counting instructions in two different ISAs without context is not
meaningful.

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-05
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/84792] [6/7/8 Regression] ICE with broken typedef of a struct

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

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

[Bug target/85216] New: Performance issue with PHP on ppc64 systems

[tpearson at raptorengineering dot com]

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

Bug ID: 85216
   Summary: Performance issue with PHP on ppc64 systems
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tpearson at raptorengineering dot com
  Target Milestone: ---

On ppc64[el] systems, GCC emits suboptimal code for the PHP VM (version 7.2.3)
that results in significant performance loss versus a standard x86 machine. 
This centers around the HYBRID_BREAK() function converting into two slow
instructions on ppc64el versus one fast instruction on x86.

x86 generated assembly example:

.L33600:
# php7.2-7.2.3/Zend/zend_vm_execute.h:59809: 
ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);
.loc 2 59809 0
callZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER #
jmp *(%r15) # opline.199_67->handler

ppc64el generated assembly example:

.L35825:
 # php7.2-7.2.3/Zend/zend_vm_execute.h:59809: 
ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);
.loc 2 59809 0
bl ZEND_VERIFY_ABSTRACT_CLASS_SPEC_HANDLER   #
 # php7.2-7.2.3/Zend/zend_vm_execute.h:59810: 
HYBRID_BREAK();
.loc 2 59810 0
ld 9,0(29)   # opline.200_67->handler, gotovar.1505_2678
mtctr 9  # gotovar.1505_2678, gotovar.1505_2678
bctr

Note the additional assembly instructions emitted for HYBRID_BREAK(); perf
indicates these are consuming considerable amounts of time on ppc64el while the
equivalent jmp on x86 consumes almost no time at all.

I'm not sure if this is a POWER9 quirk (cache problem) or what the correct
assembler should be, just that there is a serious performance loss with the
current emitted assembler versus the x86 equivalent.

Thanks!

[Bug c++/84938] [7/8 Regression] internal compiler error: in gen_reg_rtx, at emit-rtl.c:1187 (gen_reg_rtx()/maybe_legitimize_operand())

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 00:09:10 2018
New Revision: 259108

URL: https://gcc.gnu.org/viewcvs?rev=259108=gcc=rev
Log:
PR c++/84938 - ICE with division by ~-1.

* call.c (set_up_extended_ref_temp): Call cp_fully_fold.

Added:
trunk/gcc/testsuite/g++.dg/expr/div-by-zero1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/84936] [8 Regression] ICE with unexpanded parameter pack

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 00:09:05 2018
New Revision: 259107

URL: https://gcc.gnu.org/viewcvs?rev=259107=gcc=rev
Log:
PR c++/84936 - ICE with unexpanded pack in mem-initializer.

* parser.c (cp_parser_mem_initializer_list): Call
check_for_bare_parameter_packs.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic175.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/84936] [8 Regression] ICE with unexpanded parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/47815] Tail call regression with GCC snapshot

[adam at consulting dot net.nz]

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

Adam Warner  changed:

   What|Removed |Added

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

--- Comment #5 from Adam Warner  ---
(In reply to Eric Gallager from comment #4)
> Is this still an issue with newer versions of gcc?

I'm delighted to inform you the regression is resolved. Jumps instead of calls
are generated and optimisation for size is significantly improved (from 18
bytes down to 10 bytes due to the elimination of a duplicate xor instruction
and the use of smaller relative jump instructions):

$ gcc-snapshot.sh --version
gcc (Debian 20180322-1) 8.0.1 20180322 (experimental) [trunk revision 258755]
...

$ gcc-snapshot.sh -Os tail_call_regression.c && objdump -d -m i386:x86-64 a.out
|less

...
00400576 :
  400576:   31 c0   xor%eax,%eax
  400578:   85 ff   test   %edi,%edi
  40057a:   74 02   je 40057e 
  40057c:   eb a8   jmp400526 
  40057e:   eb ce   jmp40054e 
...

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
I don't think this is just an ICE on invalid: we can trivially fix the snippet
as:

template  struct remove_reference {};
template  struct remove_reference<_Tp &> {
  typedef _Tp type;
};
template 
constexpr typename remove_reference<_Tp>::type &(_Tp &&__t) noexcept {
return static_cast::type&&>(__t);
}
template  struct vector {
  vector(vector &&) noexcept {}
};
template  struct any_container {
  vector v;
  operator vector &&() && { return move(v); }
};
struct buffer_info {
  vector shape;
  buffer_info(any_container shape_in) : shape(move(shape_in)) {}
};

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
> Started somewhere between r258751 (unaffected) and r258755 (affected)

Probably started at r258755 (fix for PR c++/81311)

[Bug c++/85215] [8 Regression] ICE: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Started somewhere between r258751 (unaffected) and r258755 (affected)

[Bug c++/85215] New: "gcc_assert (!force_elide);" failure

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 85215
   Summary: "gcc_assert (!force_elide);" failure
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43847=edit
Reproducer

The downstream bug report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1562194
describes an ICE due to this assertion failing:

8243  gcc_assert (!force_elide);

I'm attaching a minimized reproducer, which ICEs on current trunk (r259106),
with -std=c++1z.

$ ./xg++ -B. -c /tmp/rhbz1562194.cc -std=c++1z 
/tmp/rhbz1562194.cc: In constructor
‘buffer_info::buffer_info(any_container)’:
/tmp/rhbz1562194.cc:17:66: internal compiler error: in build_over_call, at
cp/call.c:8243
   buffer_info(any_container shape_in) : shape(move(shape_in)) {}
  ^
0x823faa build_over_call
../../src/gcc/cp/call.c:8243
0x8298e3 build_new_method_call_1
../../src/gcc/cp/call.c:9366
0x829f29 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:9441
0x826f1b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:8969
0x954e20 expand_default_init
../../src/gcc/cp/init.c:1887
0x9554a3 expand_aggr_init_1
../../src/gcc/cp/init.c:2002
0x954053 build_aggr_init(tree_node*, tree_node*, int, int)
../../src/gcc/cp/init.c:1742
0x950227 perform_member_init
../../src/gcc/cp/init.c:847
0x9527d3 emit_mem_initializers(tree_node*)
../../src/gcc/cp/init.c:1293
0xad0a7c finish_mem_initializers(tree_node*)
../../src/gcc/cp/semantics.c:1704
0x9e03b5 cp_parser_mem_initializer_list
../../src/gcc/cp/parser.c:14440
0x9dfc74 cp_parser_ctor_initializer_opt
../../src/gcc/cp/parser.c:14353
0x9eeb48 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:21803
0x9f9053 cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.c:26839
0x9fb8dc cp_parser_late_parsing_for_member
../../src/gcc/cp/parser.c:27719
0x9f141a cp_parser_class_specifier_1
../../src/gcc/cp/parser.c:22757
0x9f14f7 cp_parser_class_specifier
../../src/gcc/cp/parser.c:22783
0x9e43a8 cp_parser_type_specifier
../../src/gcc/cp/parser.c:16766
0x9de948 cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:13617
0x9dd071 cp_parser_simple_declaration
../../src/gcc/cp/parser.c:12927
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[munroesj at gcc dot gnu.org]

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

--- Comment #9 from Steven Munroe  ---
I suggested fixing the emmintrin.h source for both eventually ...

If you only fix AT11 then sometime later some will discover the difference and
try fix it. And likely break it again.

So fix AT immediately (with comments for why). Then when gcc trunk opens up.
fix it there as a code clean up and ask for a backport to gcc8 stable.

Because if you leave it alone in gcc 8. it might break again in gcc 9 :-/

[Bug c++/85214] New: ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562

[janpmoeller at gmx dot de]

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

Bug ID: 85214
   Summary: ICE on valid C++17 code on x86_64-linux-gnu: in
tsubst_copy, at cp/pt.c:14562
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janpmoeller at gmx dot de
  Target Milestone: ---

Created attachment 43846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43846=edit
preprocessed *.i* file

Below code leads to an ICE with gcc 7.3 and previous 7.x versions. It compiles
fine with clang 6.0.0 and clang 5.0.0.

Note that I've translated below console output to english manually since I'm
on a different locale.

---

$ g++ -v
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7.3.0/configure --prefix /usr/local/gcc-7.3.0
Thread modell: posix
gcc version 7.3.0 (GCC)


$ g++ -c -std=c++17 gcc_bug.cpp
gcc_bug.cpp: In instantiation of »main()::::
[with auto:2 = std::integral_constant; auto:1 =
std::integral_constant]«:
gcc_bug.cpp:8:51:   required by »constexpr void static_for(F&&,
std::index_sequence) [with F = main():: [mit auto:1 =
std::integral_constant]::; long unsigned
int ...s = {0, 1, 2, 3}; std::index_sequence =
std::integer_sequence]«
gcc_bug.cpp:14:15:   required by »constexpr void static_for(F&&) [with long
unsigned int iterations = 4; F = main():: [mit auto:1 =
std::integral_constant]::]«
gcc_bug.cpp:26:37:   required by »constexpr void static_for(F&&,
std::index_sequence) [with F = main()::; long unsigned
int ...s = {0, 1, 2, 3}; std::index_sequence =
std::integer_sequence]«
gcc_bug.cpp:14:15:   required by »constexpr void static_for(F&&) [with long
unsigned int iterations = 4; F = main()::]«
gcc_bug.cpp:32:6:   required from here
gcc_bug.cpp:29:27: internal compiler error: in tsubst_copy, at cp/pt.c:14562
 if constexpr (std::is_same_v)
   ^~~
0x616be7 tsubst_copy
../../gcc-7.3.0/gcc/cp/pt.c:14562
0x61e5ee tsubst_copy
../../gcc-7.3.0/gcc/cp/pt.c:14538
0x61e5ee tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-7.3.0/gcc/cp/pt.c:17861
0x6143a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-7.3.0/gcc/cp/pt.c:16700
0x6143a7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:16581
0x627fc2 tsubst_template_args
../../gcc-7.3.0/gcc/cp/pt.c:11792
0x6288cc tsubst_aggr_type
../../gcc-7.3.0/gcc/cp/pt.c:11994
0x616fb6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-7.3.0/gcc/cp/pt.c:14054
0x627fc2 tsubst_template_args
../../gcc-7.3.0/gcc/cp/pt.c:11792
0x61da01 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-7.3.0/gcc/cp/pt.c:16767
0x6143a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-7.3.0/gcc/cp/pt.c:16700
0x6143a7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:16581
0x613ad5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:16019
0x614245 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:15828
0x6140db tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:16058
0x614245 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:15828
0x6140db tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:16058
0x612235 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-7.3.0/gcc/cp/pt.c:15813
0x612235 instantiate_decl(tree_node*, bool, bool)
../../gcc-7.3.0/gcc/cp/pt.c:23021
0x64f173 maybe_instantiate_decl
../../gcc-7.3.0/gcc/cp/decl2.c:5021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

---

#include 
#include 
#include 

template
constexpr void static_for(F&& function, std::index_sequence)
{
[[maybe_unused]] int unpack[] = { 0,
(function(std::integral_constant{}), 0)... };
}

template
constexpr void static_for(F&& function)
{
static_for(std::forward(function),
std::make_index_sequence());
}

int main()
{
using some_types = 

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Jens, see the discussion in https://bugs.llvm.org/show_bug.cgi?id=22763

Jason, should this be closed as FIXED for 6.3 and up? I believe what Jens
observes is the intended behaviour of GCC and Clang now.

[Bug libstdc++/67632] explicit instantiation omits copy constructor and others

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #13 from Jonathan Wakely  ---
It was fixed by the patches for PR 57728 so seems to be a dup of that.

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

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jlink at drw dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 67632 has been marked as a duplicate of this bug. ***

[Bug c++/84938] [7/8 Regression] internal compiler error: in gen_reg_rtx, at emit-rtl.c:1187 (gen_reg_rtx()/maybe_legitimize_operand())

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug sanitizer/85213] [8 Regression] -fsanitize=undefined internal compiler error: in fold_convert_loc, at fold-const.c:2402

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-04
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|-fsanitize=undefined|[8 Regression]
   |internal compiler error: in |-fsanitize=undefined
   |fold_convert_loc, at|internal compiler error: in
   |fold-const.c:2402   |fold_convert_loc, at
   ||fold-const.c:2402
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r255947.

[Bug sanitizer/85213] New: -fsanitize=undefined internal compiler error: in fold_convert_loc, at fold-const.c:2402

[vegard.nossum at oracle dot com]

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

Bug ID: 85213
   Summary: -fsanitize=undefined internal compiler error: in
fold_convert_loc, at fold-const.c:2402
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Input (valid AFAICT):

int f(int x) {
  return (__builtin_expect(({ x != 0; }) ? 0 : 1, 3) == 0) * -1 << 0;
}

Output:

$ cc1plus -O1 -fsanitize=undefined -g
 int f(int)
Analyzing compilation unit

output/ice-fold_covert_loc.cc:2:27: internal compiler error: in
fold_convert_loc, at fold-const.c:2402
   return (__builtin_expect(({ x != 0; }) ? 0 : 1, 3) == 0) * -1 << 0;
   ^~
0x1fb2e1b fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/fold-const.c:2401
0x227d824 gimplify_cond_expr
/home/vegard/git/gcc/gcc/gimplify.c:4034
0x222a3a6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11391
0x2236ae1 gimplify_stmt(tree_node**, gimple**)
/home/vegard/git/gcc/gcc/gimplify.c:6658
0x227cfbe gimplify_cond_expr
/home/vegard/git/gcc/gcc/gimplify.c:4022
0x222a3a6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11391
0x225b10c gimplify_expr
/home/vegard/git/gcc/gcc/gimplify.c:12430
0x22606a8 gimplify_arg(tree_node**, gimple**, unsigned int, bool)
/home/vegard/git/gcc/gcc/gimplify.c:3176
0x2262d8b gimplify_call_expr
/home/vegard/git/gcc/gcc/gimplify.c:3382
0x222936f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11406
0x2227a92 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:12159
0x22234a7 internal_get_tmp_var
/home/vegard/git/gcc/gcc/gimplify.c:575
0x222e2e0 get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
/home/vegard/git/gcc/gcc/gimplify.c:628
0x222e2e0 gimplify_save_expr
/home/vegard/git/gcc/gcc/gimplify.c:5931
0x222e2e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11734
0x2227a92 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:12159
0x2227ac0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:12161
0x227d943 gimplify_cond_expr
/home/vegard/git/gcc/gcc/gimplify.c:4063
0x222a3a6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11391
0x227c58d gimplify_stmt(tree_node**, gimple**)
/home/vegard/git/gcc/gcc/gimplify.c:6658
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Built from r259106.

Test case was minimised by C-Reduce.

It seems -fsanitize=shift is enough to trigger it. The shift is by 0, though,
so it should be valid (even though the shifted value is potentially negative).

7.3.0 seems to accept it just fine.

[Bug tree-optimization/85212] New: Parallelizable loop isn't unrolled [regression bug?]

[robertw89 at googlemail dot com]

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

Bug ID: 85212
   Summary: Parallelizable loop isn't unrolled [regression bug?]
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robertw89 at googlemail dot com
  Target Milestone: ---

The compiler fails to unroll the loop (partially).

compiled with -O3  -mavx  -mavx2  -mfma -fno-math-errno -ffast-math   
-floop-parallelize-all -ftree-parallelize-loops=8

void testAutoParr(int *x) {
for (int i = 0; i < 1000; i++){
x[2*i+1] = x[2*i];
}
}

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

  Known to fail|8.0 |7.3.0

--- Comment #7 from Volker Reichelt  ---
Jason, this got fixed on trunk by your fix for PR85141.
Do you want to add any testcases from this bug?

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

[andrew at sifive dot com]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #6 from Andrew Waterman  ---
FWIW, the little-endian MIPS backend does the same thing as RISC-V here (GCC
version 8.0.0 20170509 (experimental)).

[Bug c++/84221] [6/7 Regression] spurious -Wunused warning on a variable of a template type declared unused

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 19:59:20 2018
New Revision: 259106

URL: https://gcc.gnu.org/viewcvs?rev=259106=gcc=rev
Log:
PR c++/84221
* g++.dg/warn/Wunused-var-32.C: Test explicit specialization.

Modified:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-32.C

[Bug c++/80026] [pending testcase installation] passing unresolved function pointer to variadic function template yields "too many arguments" error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |INVALID
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #7 from Paolo Carlini  ---
Thanks Alexandre for reminding me.

[Bug c++/80026] [pending testcase installation] passing unresolved function pointer to variadic function template yields "too many arguments" error

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Apr  4 19:57:33 2018
New Revision: 259105

URL: https://gcc.gnu.org/viewcvs?rev=259105=gcc=rev
Log:
2018-04-04  Paolo Carlini  

PR c++/80026
* g++.dg/cpp0x/variadic174.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic174.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/85172] internal compiler error: unexpected expression '' of kind asm_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-04
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk (so far).

[Bug inline-asm/85172] internal compiler error: unexpected expression '' of kind asm_expr

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  4 19:55:56 2018
New Revision: 259104

URL: https://gcc.gnu.org/viewcvs?rev=259104=gcc=rev
Log:
PR inline-asm/85172
* constexpr.c (cxx_eval_builtin_function_call): For calls to
builtin_valid_in_constant_expr_p functions, don't call
cxx_eval_constant_expression if argument is not
potential_constant_expression.

* g++.dg/ext/builtin13.C: New test.
* g++.dg/ext/atomic-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/atomic-4.C
trunk/gcc/testsuite/g++.dg/ext/builtin13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Peter Bergner  ---
Committed on the GCC 7 release branch now too.  Closing as fixed.

[Bug rtl-optimization/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Wed Apr  4 19:51:32 2018
New Revision: 259103

URL: https://gcc.gnu.org/viewcvs?rev=259103=gcc=rev
Log:
gcc/
Backport from mainline
2018-04-04  Peter Bergner  

PR rtl-optimization/84878
* ddg.c (add_cross_iteration_register_deps): Use DF_REF_BB to determine
the basic block.  Assert the use reference is not artificial and that
it has an associated insn.

gcc/testsuite/
Backport from mainline
2018-04-04  Peter Bergner  

PR rtl-optimization/84878
* gcc.target/powerpc/pr84878.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84878.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/ddg.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This behaviour is target-dependent. If the target defines NO_IMPLICIT_EXTERN_C
then it doesn't happen.

[Bug c++/85146] ICE with __direct_bases for declared but not defined struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far (and is considered now invalid, so not sure if we
should backport it).

[Bug libstdc++/67632] explicit instantiation omits copy constructor and others

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
It seems to have been fixed in 6.3.0

tmp$ ~/gcc/6.2.0/bin/g++ -E t.cc -o t.ii
tmp$ ~/gcc/6.2.0/bin/g++ -E x.cc -o x.ii
tmp$ ~/gcc/6.2.0/bin/g++ t.ii x.ii
/tmp/ccdXPlNS.o: In function `copy(std::unordered_map > const&)':
x.cc:(.text+0x1f): undefined reference to `std::unordered_map
>::unordered_map(std::unordered_map > const&)'
collect2: error: ld returned 1 exit status
tmp$ ~/gcc/6.3.0/bin/g++ t.ii x.ii

I'll bisect it.

[Bug preprocessor/85211] New: -isystem automatically adds extern "C" to includes

[blastrock at free dot fr]

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

Bug ID: 85211
   Summary: -isystem automatically adds extern "C" to includes
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blastrock at free dot fr
  Target Milestone: ---

This is a very old problem documented in GCC 6:

https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/System-Headers.html#System-Headers

(see the last paragraph)

However that part was removed from the documentation in GCC 7:

https://gcc.gnu.org/onlinedocs/gcc-7.3.0/cpp/System-Headers.html#System-Headers

I would suggest putting it back since that legacy behavior is still present.
Also, it would be nice to have a documented way to opt out from it.

If it is of any importance, I have that problem with the g++ compiled in the
vitasdk (
https://github.com/vitasdk/autobuilds/releases/download/master-linux-v771/vitasdk-x86_64-linux-gnu-2018-04-02_17-48-36.tar.bz2
) that should have been built with the following script:
https://github.com/vitasdk/buildscripts/blob/master/CMakeLists.txt . The target
arch is arm-vita-eabi.

[Bug c++/85146] ICE with __direct_bases for declared but not defined struct

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  4 19:34:18 2018
New Revision: 259101

URL: https://gcc.gnu.org/viewcvs?rev=259101=gcc=rev
Log:
PR c++/85146
* cp-tree.h (calculate_bases, calculate_direct_bases): Add complain
argument.
* semantics.c (calculate_bases): Add complain argument.  Use
complete_type_or_maybe_complain instead of just complete_type and
return an empty vector if it fails.  Move make_tree_vector () call
after early return.  Formatting fixes.
(calculate_direct_bases): Likewise.  Call release_tree_vector at the
end.
(dfs_calculate_bases_post, calculate_bases_helper): Formatting fixes.
* pt.c (tsubst_pack_expansion): Adjust calculate_bases and
calculate_direct_bases callers, formatting fixes.

* g++.dg/ext/bases2.C: Expect extra error diagnostics.
* g++.dg/ext/bases3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/bases3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/bases2.C

[Bug c++/85210] New: ICE with broken structured binding in template

[reichelt at gcc dot gnu.org]

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

Bug ID: 85210
   Summary: ICE with broken structured binding in template
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-std=c++1z") triggers
an ICE since GCC 7.1.0 (structured bindings were introduced):


struct A { int i; };

template void foo(int j)
{
  auto [j] = A{j};
}

void bar()
{
  foo<0>(0);
}


bug.cc: In function 'void foo(int)':
bug.cc:5:10: error: declaration of 'auto j' shadows a parameter
   auto [j] = A{j};
  ^
bug.cc: In instantiation of 'void foo(int) [with int  = 0]':
bug.cc:10:11:   required from here
bug.cc:5:8: internal compiler error: in fit_decomposition_lang_decl, at
cp/lex.c:724
   auto [j] = A{j};
^~~
0x61802a fit_decomposition_lang_decl(tree_node*, tree_node*)
../../gcc/gcc/cp/lex.c:724
0x8a2868 cp_finish_decomp(tree_node*, tree_node*, unsigned int)
../../gcc/gcc/cp/decl.c:7545
0x9746fd tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16409
0x96f15f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x96e2f8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16249
0x96e2f8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23659
0x9932db instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23775
0x8b893b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4724
Please submit a full bug report, [etc.]

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/85209] New: [8 Regression] ICE with lambda and structured binding

[reichelt at gcc dot gnu.org]

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

Bug ID: 85209
   Summary: [8 Regression] ICE with lambda and structured binding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-std=c++17") triggers
an ICE on trunk:

===
template void foo()
{
  auto [a] = []{};
};

void bar()
{
  foo<0>();
}
===

bug.cc: In instantiation of 'void foo() [with int  = 0]':
bug.cc:8:10:   required from here
bug.cc:3:8: internal compiler error: in tsubst_decomp_names, at cp/pt.c:16223
   auto [a] = []{};
^~~
0x6456bb tsubst_decomp_names
../../gcc/gcc/cp/pt.c:16223
0x974695 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16403
0x971764 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16264
0x96f15f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16561
0x96e2f8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16249
0x96e2f8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23659
0x9932db instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23775
0x8b893b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4724
Please submit a full bug report, [etc.]

The regression was introduced between 2017-08-19 and 2017-09-02.
Before, the code was correctly rejected:

bug.cc: In instantiation of 'void foo() [with int  = 0]':
bug.cc:8:10:   required from here
bug.cc:3:8: error: cannot decompose lambda closure type 'foo() [with int
 = 0]::'
   auto [a] = []{};
^~~

[Bug c++/85006] [7/8 Regression] [concepts] ICE with bogus parameter pack

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 19:19:34 2018
New Revision: 259100

URL: https://gcc.gnu.org/viewcvs?rev=259100=gcc=rev
Log:
PR c++/85006 - -fconcepts ICE with A return type

* pt.c (tsubst_pack_expansion): Allow unsubstituted auto pack.

Added:
trunk/gcc/testsuite/g++.dg/concepts/auto4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/85208] ICE with #pragma weak and structured binding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-04
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I'll handle this.

[Bug c++/84221] [6/7/8 Regression] spurious -Wunused warning on a variable of a template type declared unused

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 19:10:32 2018
New Revision: 259098

URL: https://gcc.gnu.org/viewcvs?rev=259098=gcc=rev
Log:
PR c++/84221 - bogus -Wunused with attribute and template.

* decl2.c (is_late_template_attribute): Handle unused and used
normally on non-TYPE_DECL.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 19:10:38 2018
New Revision: 259099

URL: https://gcc.gnu.org/viewcvs?rev=259099=gcc=rev
Log:
PR c++/85200 - ICE with constexpr if in generic lambda.

* tree.c (cp_walk_subtrees): Walk into DECL_EXPR in templates.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if18.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug rtl-optimization/84878] ICE: Segmentation fault (in add_cross_iteration_register_deps)

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
(In reply to Peter Bergner from comment #5)
> ICEs on GCC 7 but not with GCC 6.

Backport to GCC 7 bootstraps and regtests with no regressions.  Waiting for
approval to commit it to the GCC 7 branch.

[Bug c++/85208] New: ICE with #pragma weak and structured binding

[reichelt at gcc dot gnu.org]

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

Bug ID: 85208
   Summary: ICE with #pragma weak and structured binding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-std=c++17") triggers
an ICE since GCC 7.1.0 (when structured bindings were introduced):

==
#pragma weak foo

struct A { int i; };

auto [a] = A();
==

bug.cc:5:6: internal compiler error: in write_unqualified_name, at
cp/mangle.c:1338
 auto [a] = A();
  ^~~
0x619dda write_unqualified_name
../../gcc/gcc/cp/mangle.c:1338
0x8e61a7 write_name
../../gcc/gcc/cp/mangle.c:937
0x8e5986 write_encoding
../../gcc/gcc/cp/mangle.c:825
0x8ea224 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3792
0x8f0070 get_mangled_id
../../gcc/gcc/cp/mangle.c:3814
0x8f0070 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3852
0x1147c4d decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:687
0xa4cfdc maybe_apply_pragma_weak(tree_node*)
../../gcc/gcc/c-family/c-pragma.c:291
0x8abea4 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:5094
0x94466d cp_parser_decomposition_declaration
../../gcc/gcc/cp/parser.c:13262
0x94466d cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12979
0x945218 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12874
0x9491a2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12772
0x9495b1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12648
0x9498a4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x9498a4 c_parse_file()
../../gcc/gcc/cp/parser.c:39016
0xa494d6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug c++/85006] [7/8 Regression] [concepts] ICE with bogus parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug libstdc++/67632] explicit instantiation omits copy constructor and others

[matt at godbolt dot org]

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

Matt Godbolt  changed:

   What|Removed |Added

 CC||matt at godbolt dot org

--- Comment #11 from Matt Godbolt  ---
I was unable to reproduce with gcc 7.2
~ $ cat > /tmp/t.cc
#include 
template class std::unordered_map;
~ $ cat > /tmp/x.cc
#include 
extern template class std::unordered_map;
std::unordered_map copy(
   const std::unordered_map & a) { return a; }

main() {}

 $ ~/dev/cpp-build-tools/g++ --version
g++ ('DRW) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++11 -c t.cc
$ g++ -std=c++11 t.o x.cc
$ ./a.out 
$

[Bug c++/85205] Optimalisation fails when using a union to allocate space on stack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is UB, but as extension we try to accept such code as poor man's flexible
array members.
This works on the trunk as expected starting with r255775 aka PR77291 fix.

[Bug other/85207] New: Documentation says that -Qn is the default but looks like -Qy is the default

[rofirrim at gmail dot com]

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

Bug ID: 85207
   Summary: Documentation says that -Qn is the default but looks
like -Qy is the default
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rofirrim at gmail dot com
  Target Milestone: ---

Hi all,

  https://gcc.gnu.org/onlinedocs/gcc/System-V-Options.html

reads

"
   -Qy
   Identify the versions of each tool used by the compiler, in a .ident
assembler directive in the output.

   -Qn
   Refrain from adding .ident directives to the output file (this is the
default).

"


but in all the tests I've done gcc always emits .ident which seems to suggest
that the default is actually -Qy, not -Qn as the text seems to suggest.

Perhaps this is target-dependent but even in that case the documentation may
need updating to reflect that.

Kind regards,
Roger

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug target/82989] [6/7 regression] Inexplicable use of NEON for 64-bit math

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|7.4 |6.5

[Bug other/85161] [8 regression] Test case failures in libbacktrace on powerpc64 BE starting with r253456

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug c++/84221] [6/7/8 Regression] spurious -Wunused warning on a variable of a template type declared unused

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-04
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

[thopre01 at gcc dot gnu.org]

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

--- Comment #1 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Apr  4 17:31:46 2018
New Revision: 259097

URL: https://gcc.gnu.org/viewcvs?rev=259097=gcc=rev
Log:
[ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification says
  the intrinsic should return true for a nonsecure caller and a
  nonsecure caller is characterized with LR's lsb being 0

This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This commit fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The commit also reorganize the scan directives in cmse-1.c to more
easily identify what function they are intended to test in the file.

2018-04-04  Thomas Preud'homme  

gcc/
PR target/85203
* config/arm/arm-builtins.c (arm_expand_builtin): Change
expansion to perform a bitwise AND of the argument followed by a
boolean negation of the result.

gcc/testsuite/
PR target/85203
* gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
to match a single insn of the baz function.  Move scan directives at
the end of the file below the functions they are trying to test for
better readability.
* gcc.target/arm/cmse/cmse-16.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/cmse/cmse-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c

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

[pc at us dot ibm.com]

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

--- Comment #8 from Paul Clarke  ---
(In reply to Steven Munroe from comment #7)
> Please try the same test with AT11 gcc7. I know I hit this!

voila!

$ /opt/at11.0/bin/gcc -o 83402 83402.c -DNO_WARN_X86_INTRINSICS -Wall
-mcpu=power8 -O3
In file included from
/opt/at11.0/lib/gcc/powerpc64le-linux-gnu/7.3.1/include/emmintrin.h:62:0,
 from 83402.c:2:
/opt/at11.0/lib/gcc/powerpc64le-linux-gnu/7.3.1/include/emmintrin.h: In
function ‘main’:
/opt/at11.0/lib/gcc/powerpc64le-linux-gnu/7.3.1/include/emmintrin.h:1513:20:
error: argument 1 must be a 5-bit signed literal
  lshift = (__v4su) vec_splat_s32(__B);
^
$ rpm -q advance-toolchain-at11.0-devel
advance-toolchain-at11.0-devel-11.0-3.ppc64le

Now the question is whether to bother fixing this:
1. in GCC 8's rs6000/emmintrin.h, since it's not really "broken" there, and
backport that AT 11 (sounds a little silly)
2. backport the GCC 8 change that fixes this to AT 11 (sounds hard)
3. change only AT 11's emmintrin.h

Any strong opinions?  Otherwise, I'm leaning toward option (3).

[Bug other/85161] [8 regression] Test case failures in libbacktrace on powerpc64 BE starting with r253456

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  4 17:18:14 2018
New Revision: 259096

URL: https://gcc.gnu.org/viewcvs?rev=259096=gcc=rev
Log:
PR other/85161
* elf.c (elf_zlib_fetch): Fix up predefined macro names in test for
big endian, only use 32-bit loads if endianity macros are predefined
and indicate big or little endian.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/elf.c

[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Yeah, but it is too late to make GCC 8.  Do you want to do the patch for GCC 9?
Ideally it goes into binutils, first.

[Bug c++/85200] [8 Regression] ICE in constexpr-if in lambda in template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-04
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r259043.

[Bug c++/85205] Optimalisation fails when using a union to allocate space on stack

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Mijzelf from comment #0)

> args.data[ i ].var1 = i;

This is undefined behaviour when i>0 because the array only has one element.
It's irrelevant that the union has additional space, the array doesn't.

> If the code is changed so data has 0 elements:
> 
> struct X{
> int length;
> 
> struct Y {
> int var1;
> int var2;
> } data[ 0 ];
> };
> 
> the code works as expected

This works due to a GNU extension:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero-Length

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Another testcase running into this.

char *bar (void);
__INTPTR_TYPE__ baz (void);

void
foo (__INTPTR_TYPE__ *q)
{
  char *p = bar ();
  __INTPTR_TYPE__ a = baz ();
  __INTPTR_TYPE__ b = baz ();
  int i = 0;
#define X q[i++] = a; q[i++] = b; a = a + b; b = b + a;
#define Y X X X X X X X X X X
#define Z Y Y Y Y Y Y Y Y Y Y
  Z Z Z Z Z Z Z Z Z Z
  p[a] = 1;
  p[b] = 2;
}

With Y X X X instead of the 10 Zs I see with -O1 -ftime-report:
 dead store elim1   :   0.43 ( 81%)   0.00 (  0%)   0.43 ( 81%)
  6 kB (  0%)
With Y X X X X:
 dead store elim1   :   1.15 ( 88%)   0.00 (  0%)   1.15 ( 88%)
  7 kB (  0%)
With Y X X X X X:
 dead store elim1   :   3.29 ( 92%)   0.00 (  0%)   3.29 ( 91%)
  7 kB (  0%)
With Y X X X X X X:
 dead store elim1   :   9.18 ( 93%)   0.00 (  0%)   9.19 ( 93%)
  8 kB (  0%)
With Y X X X X X X X:
 dead store elim1   :  24.71 ( 94%)   0.00 (  0%)  24.73 ( 94%)
  8 kB (  1%)
With Y X X X X X X X X:
 dead store elim1   :  68.89 ( 94%)   0.00 (  0%)  68.94 ( 94%)
  9 kB (  1%)
With Y X X X X X X X X X:
 dead store elim1   : 190.42 ( 95%)   0.00 (  0%) 190.56 ( 95%)
  9 kB (  1%)
With Y Y:
 dead store elim1   : 522.59 ( 95%)   0.00 (  0%) 522.96 ( 95%)
 10 kB (  1%)

[Bug c++/85141] [6/7/8 Regression] ICE with pointer arithmetic of static member function address

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 8.  Doesn't seem worth backporting, since this is really
ill-formed.

[Bug c++/85148] [6/7/8 Regression] ICE with NSDMI and this pointer

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |7.4

--- Comment #4 from Jason Merrill  ---
Fixed for 7.4; doesn't seem like a priority for GCC 6.

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:46:00 2018
New Revision: 259094

URL: https://gcc.gnu.org/viewcvs?rev=259094=gcc=rev
Log:
PR c++/85118 - wrong error with generic lambda and std::bind.

* call.c (add_template_conv_candidate): Disable if there are any
call operators.

Added:
   
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic17.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/call.c

[Bug c++/85148] [6/7/8 Regression] ICE with NSDMI and this pointer

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:45:53 2018
New Revision: 259093

URL: https://gcc.gnu.org/viewcvs?rev=259093=gcc=rev
Log:
PR c++/85148 - ICE with 'this' in array NSDMI.

* tree.c (replace_placeholders_r): Use handled_component_p.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr11.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/tree.c

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #33)
> Probably impossible to fix without breaking the ABI again, but there should
> have been two __throw_ios_failure entries (and callers be "versioned" as
> well).

I considered that, but for 99.99% of cases the caller is inside libstdc++.so
not in user code (because the iostream classes are explicitly instantiated in
the library), so there's no much point. The library is still only going to call
one symbol, either the old one or the new one. For the other 0.01% of calls,
having two versions of the function would be an ODR violation, which in
practice would mean that non-inlined calls from different translation units
have vague linkage and the linker discards all but one copy, which you'd have
no control over whether it keeps a copy calling the new version or the old.

To version the calls would have required either versioning the entire iostream
hierarchy (and having two or each of std::cout, std::cin, std::cerr, and
std::clog) or some nasty hack like every iostreams operation setting a
thread-local variable to note whether the caller was new code or old code, and
check that flag when throwing to decide which type to throw. But even that
wouldn't be right, because the caller might be using one ABI and the location
of the catch be using the other one. There's no good solution.

> At least the old symbol should have been preserved as backward compatible
> and a new with a new version be added ... should have been ...

Maybe, but again, since the caller is (almost always) in the library not in
user code, the old symbol would never be called.

Although __throw_ios_failure() is visible to user code, they shouldn't ever be
calling it directly. It's not a public API.

[Bug c++/85118] [6/7/8 Regression] Error when using std::bind with a generic lambda - "cannot bind 'const volatile char&' to an rvalue of type 'const volatile char'"

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:42:44 2018
New Revision: 259090

URL: https://gcc.gnu.org/viewcvs?rev=259090=gcc=rev
Log:
PR c++/85118 - wrong error with generic lambda and std::bind.

* call.c (add_template_conv_candidate): Disable if there are any
call operators.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/85133] [7/8 Regression] [concepts] ICE with invalid concept used in variadic template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:42:50 2018
New Revision: 259091

URL: https://gcc.gnu.org/viewcvs?rev=259091=gcc=rev
Log:
PR c++/85133 - ICE with missing concept initializer.

* decl.c (cp_finish_decl): If a concept initializer is missing, use
true.

Added:
trunk/gcc/testsuite/g++.dg/concepts/var-concept7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/85135] [7/8 Regression] ICE with invalid late-specified return type

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:42:55 2018
New Revision: 259092

URL: https://gcc.gnu.org/viewcvs?rev=259092=gcc=rev
Log:
PR c++/85135 - ICE with omitted template arguments.

* decl.c (grokdeclarator): Catch deduced class type in trailing
return type.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction53.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/85148] [6/7/8 Regression] ICE with NSDMI and this pointer

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:42:33 2018
New Revision: 259088

URL: https://gcc.gnu.org/viewcvs?rev=259088=gcc=rev
Log:
PR c++/85148 - ICE with 'this' in array NSDMI.

* tree.c (replace_placeholders_r): Use handled_component_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug c++/85141] [6/7/8 Regression] ICE with pointer arithmetic of static member function address

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Apr  4 16:42:39 2018
New Revision: 259089

URL: https://gcc.gnu.org/viewcvs?rev=259089=gcc=rev
Log:
PR c++/85141 - ICE with compound assignment and static member fn.

* typeck.c (cp_build_modify_expr): Call decay_conversion for RHS of
compound assignment.

Added:
trunk/gcc/testsuite/g++.dg/expr/assign2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/parse/crash60.C

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

[munroesj at gcc dot gnu.org]

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

--- Comment #7 from Steven Munroe  ---
Ok it could be that compiler behavior changed.

You where testing gcc-trunk? 

Please try the same test with AT11 gcc7. I know I hit this!

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Any progress here?  I don't see the patch posted on gcc-patches.

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #8 from Ville Voutilainen  ---
Fixed on GCC 8, not backporting, so done.

[Bug target/84757] [7/8/9 Regression] Useless MOVs and PUSHes to store results of MUL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|7.4 |9.0
Summary|[7/8 Regression] Useless|[7/8/9 Regression] Useless
   |MOVs and PUSHes to store|MOVs and PUSHes to store
   |results of MUL  |results of MUL

--- Comment #5 from Jakub Jelinek  ---
Deferring to 9.x then.

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

[ville at gcc dot gnu.org]

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

--- Comment #7 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Apr  4 16:05:11 2018
New Revision: 259087

URL: https://gcc.gnu.org/viewcvs?rev=259087=gcc=rev
Log:
PR c++/65923

gcc/cp

PR c++/65923
* decl.c (grokfndecl): Handle standard UDL diagnostics here..
* parser.c (cp_parser_unqualified_id): ..not here.

testsuite/

PR c++/65923
* g++.dg/diagnostic/pr65923.C: New.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr65923.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c