[Bug gcov-profile/85245] [GCOV] A return statement in the if(0) block is wrongly marked as executed when they are nested in the true block of if (cond-expression) statement in gcov

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
(In reply to Yibiao Yang from comment #0)
> $ 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 a=0;
> int main() {
>   {
> int c[1];
> if (a < 1) {
>   if (0)
> return 0;
>   return 1;
> }

same bug
for(;a<1;) {
  if(0)
return 0;
  return 1;
}
 "return 0;" will also be marked as executed 
***

>   }
>   return 0;
> }
> 
> $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
> File 'small.c'
> Lines executed:80.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:int a=0;
> 1:2:int main() {
> -:3:  {
> -:4:int c[1];
> 1:5:if (a < 1) {
> -:6:  if (0)
> 1:7:return 0;
> 1:8:  return 1;
> -:9:}
> -:   10:  }
> #:   11:  return 0;
> -:   12:}
> 
> 
> Line #7 is wrongly marked as executed.

[Bug gcov-profile/85245] New: [GCOV] A return statement in the if(0) block is wrongly marked as executed when they are nested in the true block of if (cond-expression) statement in gcov

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85245
   Summary: [GCOV] A return statement in the if(0) block is
wrongly marked as executed when they are nested in the
true block of if (cond-expression) 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
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 a=0;
int main() {
  {
int c[1];
if (a < 1) {
  if (0)
return 0;
  return 1;
}
  }
  return 0;
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:80.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:int a=0;
1:2:int main() {
-:3:  {
-:4:int c[1];
1:5:if (a < 1) {
-:6:  if (0)
1:7:return 0;
1:8:  return 1;
-:9:}
-:   10:  }
#:   11:  return 0;
-:   12:}


Line #7 is wrongly marked as executed.

[Bug c++/85240] [6/7/8 Regression] ICE with function without deduced return type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-06
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Jason Merrill  ---
Yes, this behavior is intended; just like you can't explicitly specialize a
class after it's been instantiated, you can't specify attributes either.

The C++ standard is even stricter, saying "No attribute-specifier-seq shall
appertain to an explicit instantiation."

[Bug gcov-profile/85243] [GCOV] A return statement in the if(0) block is wrongly marked as executed when prefixed with an array declaration statement and followed by a "for(;cond-expression;) return;

[yangyibiao at nju dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
When:

1. removing Line #3 and Line #9, i.e., the { } block
or 
2. changing "for(;a<2;)" to "for(;1;)" 
or
3. removing Line #4

the result are both  correct.

[Bug c/85244] New: Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)

[jean at pryen dot org]

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

Bug ID: 85244
   Summary: Bad optimisation with flexible array member (may be
related to -ftree-dominator-opts)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jean at pryen dot org
  Target Milestone: ---

Created attachment 43863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43863=edit
Main program. The companion b.i is not provided but inlined

Since gcc-6 (specific version bellow), there is a bad behavior with -O1 (and
better) in the provided program that I tried to make it minimal.

[A]. `gcc-8 -O1` cause the issue 
[B]. `gcc-6 -O1` also has the issue
[C]. `gcc-5 -O1` was OK
[D]. `gcc-8 -O1 -fno-tree-dominator-opts` does not have the issue


When diffing the generated assembly code between good [D] and bad [A], it seems
that the value `val.tab[idx]` is reused as is from a saved value of
`val.tab[0]`, i.e. without considering the value of `idx`.

--- bad/m.s 2018-04-05 21:07:11.602154334 -0400
+++ good/m.s2018-04-05 21:07:11.542157334 -0400
@@ -13,11 +13,9 @@
 main:
 .LFB11:
.cfi_startproc
-   pushq   %rbx
+   subq$8, %rsp
.cfi_def_cfa_offset 16
-   .cfi_offset 3, -16
-   movl12+val(%rip), %ebx
-   movl%ebx, %esi
+   movl12+val(%rip), %esi
leaq.LC0(%rip), %rdi
movl$0, %eax
callprintf@PLT
@@ -25,13 +23,14 @@
leaq.LC1(%rip), %rdi
movl$0, %eax
callprintf@PLT
-   movl%ebx, %edx
movqidx(%rip), %rsi
+   leaqval(%rip), %rax
+   movl12(%rax,%rsi,4), %edx
leaq.LC2(%rip), %rdi
movl$0, %eax
callprintf@PLT
movl$0, %eax
-   popq%rbx
+   addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc


Note that the following changes in the source also cause the issue (and the
diff in m.s) to disappear:

* removing `const` from the `extern const struct s val`
* removing or changing the types of `s.a` and `s.b`
* defining the const `val` inside the source file

---

Compilation line:

gcc-8 -v ../m.c ../b.c -O1 -save-temps

Output:

Using built-in specs.
COLLECT_GCC=gcc-8
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='Debian 8-20180321-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,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 --with-target-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 --without-cuda-driver
--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.1 20180321 (experimental) [trunk revision 258712] (Debian
8-20180321-1) 
COLLECT_GCC_OPTIONS='-v' '-O1' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
../m.c -mtune=generic -march=x86-64 -O1 -fpch-preprocess -o m.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-O1' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -fpreprocessed m.i -quiet -dumpbase m.c
-mtune=generic -march=x86-64 -auxbase m -O1 -version -o m.s
GNU C17 (Debian 8-20180321-1) version 8.0.1 20180321 (experimental) [trunk
revision 258712] (x86_64-linux-gnu)
compiled by GNU C version 8.0.1 20180321 (experimental) [trunk revision
258712], GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version
isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Debian 8-20180321-1) version 8.0.1 20180321 (experimental) [trunk
revision 

[Bug gcov-profile/85243] New: [GCOV] A return statement in the if(0) block is wrongly marked as executed when prefixed with an array declaration statement and followed by a "for(;cond-expression;) ret

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85243
   Summary: [GCOV] A return statement in the if(0) block is
wrongly marked as executed when prefixed with an array
declaration statement and followed by a
"for(;cond-expression;) return; " statement when they
are in a dependent block 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 a=0;
int main() {
  {
int d[1];
if (0)
  return 0;
for (; a<2;)
  return 1;
  }
  return 0;
}

$ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:80.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:int a=0;
1:2:int main() {
-:3:  {
-:4:int d[1];
-:5:if (0)
1:6:  return 0;
1:7:for (; a<2;)
1:8:  return 1;
-:9:  }
#:   10:  return 0;
-:   11:}


**
Line #6 is wrongly marked as executed.

[Bug c++/85227] [7/8/ Regression] ICE with structured binding of a forward declared variable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

[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

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

--- Comment #29 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from Eric Gallager  ---
> [...]
> > Did this fix it?
> 
> It seems so, both according to my own testing and gcc-testresults
> postings.
> 
>   Rainer

Cool, closing accordingly then.

[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-04/msg00063.ht
   ||ml
 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
Patch discussion starts here:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00063.html

[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 #10 from Timothy Pearson  ---
(In reply to Bill Schmidt from comment #9)
> You mentioned you're on a POWER9 machine.  It could be that you have
> firmware with Spectre mitigations applied, which will affect all indirect
> branches.  It may be that you do not have Spectre mitigations applied on
> your x86 machine, in which case the comparison would be expected to be quite
> different.  Depending on firmware levels, the mitigations may be able to be
> switched off, so you should check into that first.  PHP is known to be
> sensitive to indirect branch performance.
> 
> The Power landing page for these mitigations is
> https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/. 
> From here you should be able to get to further information for your specific
> hardware and OS version.

It's even slow compared to P8 with mitigations applied.  Do you have a link to
the hostboot commit that may have enabled the P9 mitigation, or to the register
name (SCOM) that was modified to enable the mitigation?

[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 #6 from Jonathan Wakely  ---
(In reply to blastrock from comment #5)
> So is this a regression since #37727 was fixed?

PR 37727 is not fixed, it's still NEW.

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  5 21:30:47 2018
New Revision: 259156

URL: https://gcc.gnu.org/viewcvs?rev=259156=gcc=rev
Log:
PR c++/85209
* pt.c (tsubst_decomp_names): Don't fail or ICE if DECL_CHAIN (decl3)
is not prev, if prev == decl.

* g++.dg/cpp1z/decomp39.C: New test.
* g++.dg/cpp1z/decomp40.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp39.C
trunk/gcc/testsuite/g++.dg/cpp1z/decomp40.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  5 21:29:51 2018
New Revision: 259155

URL: https://gcc.gnu.org/viewcvs?rev=259155=gcc=rev
Log:
PR c++/85208
* decl.c (start_decl): For DECL_DECOMPOSITION_P decls, don't call
maybe_apply_pragma_weak here...
(cp_maybe_mangle_decomp): ... but call it here instead.

* g++.dg/cpp1z/decomp41.C: New test.

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

[Bug c++/85242] New: [6/7/8 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

Bug ID: 85242
   Summary: [6/7/8 Regression] ICE with invalid template parameter
   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 triggers an ICE on trunk since GCC 6.1.0:

==
namespace N
{
  struct A {};
}

template void foo();
==

'
in dump_template_decl, at cp/error.c:1305
 template void foo();
^
0x7163e0 dump_template_decl
../../gcc-6.1.0/gcc/cp/error.c:1305
0x718bf2 decl_to_string
../../gcc-6.1.0/gcc/cp/error.c:2955
0x718bf2 cp_printer
../../gcc-6.1.0/gcc/cp/error.c:3535
0x14b50b8 pp_format(pretty_printer*, text_info*)
../../gcc-6.1.0/gcc/pretty-print.c:631
0x14b0928 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-6.1.0/gcc/diagnostic.c:823
0x14b17ed error(char const*, ...)
../../gcc-6.1.0/gcc/diagnostic.c:1152
0x644646 duplicate_decls(tree_node*, tree_node*, bool)
../../gcc-6.1.0/gcc/cp/decl.c:1609
0x81664c pushdecl_maybe_friend_1
../../gcc-6.1.0/gcc/cp/name-lookup.c:805
0x81664c pushdecl_maybe_friend(tree_node*, bool)
../../gcc-6.1.0/gcc/cp/name-lookup.c:1298
0x819753 pushdecl_with_scope_1
../../gcc-6.1.0/gcc/cp/name-lookup.c:2295
0x81983c pushdecl_with_scope(tree_node*, cp_binding_level*, bool)
../../gcc-6.1.0/gcc/cp/name-lookup.c:2309
0x8198ef pushdecl_namespace_level(tree_node*, bool)
../../gcc-6.1.0/gcc/cp/name-lookup.c:3915
0x6b5e30 push_template_decl_real(tree_node*, bool)
../../gcc-6.1.0/gcc/cp/pt.c:5392
0x72f2da cp_parser_class_head
../../gcc-6.1.0/gcc/cp/parser.c:21951
0x72f2da cp_parser_class_specifier_1
../../gcc-6.1.0/gcc/cp/parser.c:21285
0x72f2da cp_parser_class_specifier
../../gcc-6.1.0/gcc/cp/parser.c:21582
0x72f2da cp_parser_type_specifier
../../gcc-6.1.0/gcc/cp/parser.c:15836
0x743571 cp_parser_decl_specifier_seq
../../gcc-6.1.0/gcc/cp/parser.c:12760
0x7451e6 cp_parser_parameter_declaration
../../gcc-6.1.0/gcc/cp/parser.c:20437
0x7467e9 cp_parser_template_parameter
../../gcc-6.1.0/gcc/cp/parser.c:14543
Please submit a full bug report, [etc.]

Note that the compiler even fails to properly emit the
"internal compiler error" message.
GCC 4.4 - GCC 5 wrongly accepted the code.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
I'm trying to fix this for GCC 8.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/85235] [mips] Error: branch out of range

[mattst88 at gmail dot com]

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

Matt Turner  changed:

   What|Removed |Added

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

--- Comment #1 from Matt Turner  ---
INVALID. This was caused by a bad binutils patch.

[Bug c++/85241] Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[cjdb.ns at gmail dot com]

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

--- Comment #2 from Christopher Di Bella  ---
Created attachment 43862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43862=edit
static_assert equivalent (working)

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Apr  5 20:32:18 2018
New Revision: 259153

URL: https://gcc.gnu.org/viewcvs?rev=259153=gcc=rev
Log:
PR target/85193
* config/i386/i386.md (define_attr "memory"): Handle rotate1 type.

testsuite/ChangeLog:

PR target/85193
* gcc.target/i386/pr85193.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr85193.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/85241] Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[cjdb.ns at gmail dot com]

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

--- Comment #1 from Christopher Di Bella  ---
Created attachment 43861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43861=edit
Minimal reproduction

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

[blastrock at free dot fr]

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

--- Comment #5 from blastrock at free dot fr ---
I tried using their recipe to rebuild gcc. The configure line is the following:

$ /media/usb1/vitasdkbuild/build/gcc-final-prefix/src/gcc-final/configure
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-vita-eabi
--prefix=/media/usb1/vitasdkbuild/build/vitasdk
--libdir=/media/usb1/vitasdkbuild/build/vitasdk/lib
--libexecdir=/media/usb1/vitasdkbuild/build/vitasdk/lib
--with-sysroot=/media/usb1/vitasdkbuild/build/vitasdk/arm-vita-eabi
--with-gmp=/media/usb1/vitasdkbuild/build/deps_build
--with-mpfr=/media/usb1/vitasdkbuild/build/deps_build
--with-mpc=/media/usb1/vitasdkbuild/build/deps_build
--with-isl=/media/usb1/vitasdkbuild/build/deps_build
--with-libelf=/media/usb1/vitasdkbuild/build/deps_build
--with-python-dir=share/gcc-arm-vita-eabi --enable-languages=c,c++
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls
--disable-shared --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--disable-multilib --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=neon
--with-float=hard --with-mode=thumb --with-pkgversion=GNU Tools for ARM
Embedded Processors --with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm --with-headers=yes --enable-threads=posix

You can see --with-newlib in there. However I can confirm that
NO_IMPLICIT_EXTERN_C is not defined as I tried inserting broken code in the
#ifndef NO_IMPLICIT_EXTERN_C in parser.c and it did break compilation.

So is this a regression since #37727 was fixed?

[Bug c++/85241] New: Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[cjdb.ns at gmail dot com]

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

Bug ID: 85241
   Summary: Requires-expressions, fold expressions, and member
function templates with dependent parameters don't
play nicely
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

When declaring a class template with a member function template (that has
dependent types), requires-expressions seem to ignore the dependent types.

The minimal reproduction is available below, with a compiling static_assert
equivalent: https://godbolt.org/g/Vzu5wQ.


* Affects versions: GCC 6, GCC 7, GCC trunk
* Affects platforms: Ubuntu 16.04, MSYS2
* Compiler options: -std=c++17 -fconcepts -Wall -Wextra -Wpedantic -Wconversion
-Werror
* Exact command: g++-7 -Wall -Wextra -Wpedantic -Wconversion -Werror -std=c++17
-fconcepts bad-concept.cpp
* Compiler output:

```
bad-concept.cpp:14:47:   required from here
bad-concept.cpp:9:10: error: mismatched argument pack lengths while expanding
‘C’
 void bar(Us&&...) {}
  ^~~
```

[Bug middle-end/85195] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #11)

> gcc -O2 -m27332:

"gcc -O2 -m32", the test shows dumps for 32bit x86 target.

[Bug c++/85240] New: [6/7/8 Regression] ICE with function without deduced return type

[reichelt at gcc dot gnu.org]

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

Bug ID: 85240
   Summary: [6/7/8 Regression] ICE with function without deduced
return type
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, lto
  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 "-flto") triggers an ICE
since GCC 5.1.0:

=
auto foo();

void bar()
{
  using ::foo;
}
=

during IPA pass: fnsummary
bug.cc:6:1: internal compiler error: tree code 'template_type_parm' is not
supported in LTO streams
 }
 ^
0xd8e523 lto_write_tree
../../gcc/gcc/lto-streamer-out.c:442
0xd8e523 lto_output_tree_1
../../gcc/gcc/lto-streamer-out.c:483
0xd8e523 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
../../gcc/gcc/lto-streamer-out.c:670
0xd8f42d lto_output_tree(output_block*, tree_node*, bool, bool)
../../gcc/gcc/lto-streamer-out.c:1642
0xd84b92 write_global_stream
../../gcc/gcc/lto-streamer-out.c:2492
0xd8d3ee lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
../../gcc/gcc/lto-streamer-out.c:2539
0xd8d3ee produce_asm_for_decls()
../../gcc/gcc/lto-streamer-out.c:2872
0xdeb49f write_lto
../../gcc/gcc/passes.c:2613
0xdeeb8e ipa_write_summaries_1
../../gcc/gcc/passes.c:2674
0xdeeb8e ipa_write_summaries()
../../gcc/gcc/passes.c:2734
0xaf2a52 ipa_passes
../../gcc/gcc/cgraphunit.c:2468
0xaf2a52 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2558
0xaf4a89 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2537
0xaf4a89 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2717
Please submit a full bug report, [etc.]

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> I guess it depends on what exactly a normal subreg on lhs means.
> The documentation says:
>   When used as an lvalue, 'subreg' is a word-based accessor.
>   Storing to a 'subreg' modifies all the words of REG that
>   overlap the 'subreg', but it leaves the other words of REG
>   alone.

I believe that the above wording is intended to describe the following test:

--cut here--
union u
{
  long long ll;
  int i[2];
};

union u test (union u a)
{
  a.ll >>= 3;
  a.i[0] = 5;
  a.ll <<= 3;

  return a;
}
--cut here--

gcc -O2 -m27332:

_.273r.ira shows:

(insn 8 7 9 2 (parallel [
(set (reg/v:DI 92 [ a ])
(ashiftrt:DI (reg/v:DI 92 [ a ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "subr.c":9 532 {*ashrdi3_doubleword}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 9 8 10 2 (set (subreg:SI (reg/v:DI 92 [ a ]) 0)
(const_int 5 [0x5])) "subr.c":10 82 {*movsi_internal}
 (nil))
(insn 10 9 12 2 (parallel [
(set (reg:DI 94)
(ashift:DI (reg/v:DI 92 [ a ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "subr.c":11 503 {*ashldi3_doubleword}
 (expr_list:REG_DEAD (reg/v:DI 92 [ a ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (mem/c:DI (reg/f:SI 91 [ .result_ptr ]) [1
+0 S8 A32])
(nil)

please note (insn 9), which LRA converts to:

(insn 8 7 9 2 (parallel [
(set (reg/v:DI 4 si [orig:92 a ] [92])
(ashiftrt:DI (reg/v:DI 4 si [orig:92 a ] [92])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "subr.c":9 532 {*ashrdi3_doubleword}
 (nil))
(insn 9 8 20 2 (set (reg:SI 4 si [orig:92 a ] [92])
(const_int 5 [0x5])) "subr.c":10 82 {*movsi_internal}
 (nil))
(insn 20 9 10 2 (set (reg:DI 2 cx [94])
(reg/v:DI 4 si [orig:92 a ] [92])) "subr.c":11 81 {*movdi_internal}
 (nil))
(insn 10 20 12 2 (parallel [
(set (reg:DI 2 cx [94])
(ashift:DI (reg:DI 2 cx [94])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "subr.c":11 503 {*ashldi3_doubleword}
 (expr_list:REG_EQUIV (mem/c:DI (reg/f:SI 0 ax [orig:91 .result_ptr ] [91])
[1 +0 S8 A32])
(nil)))

In the above pass, using (insn 9), the compiler inserted a 32-bit word into the
lowpart (%esi) of the multi-word register pair (%esi/%edi). In effect, "the
other words of REG" are left alone, as the documentation says.

But this wording applies only to multi-word registers. We can't use the above
wording for 512bit single-word register, since we don't know how the move will
affect the bits outside the subreg. We can say that the move "modifies all the
words of REG that overlap the 'subreg', since we have only one 512-bit word of
a 512-bit register.

So, I think that the transformation in the Comment 10 is invalid for registers
that can't be decomposed to independent word-sized registers (to use
"word-based accessor"), e.g. V32HImode xmm20. Perhaps the mentioned
alter_subreg should choose correct approach based on TARGET_HARD_REGNO_NREGS?

[Bug c++/85136] [6/7/8 Regression] ICE with array as template variable

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 19:43:39 2018
New Revision: 259152

URL: https://gcc.gnu.org/viewcvs?rev=259152=gcc=rev
Log:
PR c++/85136 - ICE with designated init in template.

* decl.c (maybe_deduce_size_from_array_init): Handle dependent
designated initializer.
(check_array_designated_initializer): Update ce->index with the
constant value.

Added:
trunk/gcc/testsuite/g++.dg/ext/desig11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug testsuite/85239] New: Tcl error running gfortran lto testsuite under Cygwin

[tkoenig at gcc dot gnu.org]

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

Bug ID: 85239
   Summary: Tcl error running gfortran lto testsuite under Cygwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

>From the same test run as PR 85238, but it looks unrelated at first glance:

Running
/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/goacc/goacc.exp ...
ERROR: tcl error sourcing
/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/lto/lto.exp.
ERROR: can't read "testname_with_flags": no such variable
while executing
"fail "$testname_with_flags $num_blank_lines blank line(s) in output""
(procedure "gcc-dg-prune" line 14)
invoked from within
"gcc-dg-prune $system $text"
(procedure "gfortran-dg-prune" line 2)
invoked from within
"${tool}-dg-prune $target_triplet $gcc_output"
(procedure "gfortran_check_compile" line 32)
invoked from within
"${tool}_check_compile "$testcase $testname link" $optstr  $dest $comp_output"
(procedure "lto-link-and-maybe-run" line 52)
invoked from within
"lto-link-and-maybe-run  "[lindex $obj_list 0]-[lindex $obj_list end]" 
$obj_list $execname $filtered ${dg-extra-ld-options}  $filtered"
(procedure "lto-execute" line 142)
invoked from within
"lto-execute $src $sid"
("foreach" body line 7)
invoked from within
"foreach src [lsort [glob -nocomplain $srcdir/$subdir/*_0.\[fF\]{,90,95,03,08}
]] {
# If we're only testing specific files and this isn't one of th..."
(file
"/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/lto/lto.exp" line 49)
invoked from within
"source /cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/lto/lto.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/lto/lto.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""

[Bug lto/85238] New: lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[tkoenig at gcc dot gnu.org]

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

Bug ID: 85238
   Summary: lto-wrapper: fatal error:
simple_object_copy_lto_debug_sections not implemented:
Invalid argument  on Cygwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Running the gfortran test suite on the 20180401 snapshot on cygwin
(current release as of today) yields some LTO errors:

FAIL: gfortran.dg/submodule_6.f08   -O3 -g  (test for excess errors)

which, upon inspection, is

Executing on host:
/cygdrive/e/Gcc/snap-bin/gcc/testsuite/gfortran7/../../gfortran
-B/cygdrive/e/Gcc/snap-bin/gcc/testsuite/gfortran7/../../ -B/c
ygdrive/e/Gcc/snap-bin/x86_64-unknown-cygwin/./libgfortran/
/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/submodule_6.f08 
-fno-diagno
stics-show-caret -fdiagnostics-color=never-O3 -g  -flto 
-B/cygdrive/e/Gcc/snap-bin/x86_64-unknown-cygwin/./libgfortran/.libs
-L/cygdrive/e/G
cc/snap-bin/x86_64-unknown-cygwin/./libgfortran/.libs
-B/cygdrive/e/Gcc/snap-bin/x86_64-unknown-cygwin/./libquadmath/.libs
-L/cygdrive/e/Gcc/snap
-bin/x86_64-unknown-cygwin/./libquadmath/.libs  -o ./submodule_6.exe   
(timeout = 300)
spawn /cygdrive/e/Gcc/snap-bin/gcc/testsuite/gfortran7/../../gfortran
-B/cygdrive/e/Gcc/snap-bin/gcc/testsuite/gfortran7/../../ -B/cygdrive/e/Gcc
/snap-bin/x86_64-unknown-cygwin/./libgfortran/
/cygdrive/e/Gcc/gcc-8-20180401/gcc/testsuite/gfortran.dg/submodule_6.f08
-fno-diagnostics-show-car
et -fdiagnostics-color=never -O3 -g -flto
-B/cygdrive/e/Gcc/snap-bin/x86_64-unknown-cygwin/./libgfortran/.libs
-L/cygdrive/e/Gcc/snap-bin/x86_64-
unknown-cygwin/./libgfortran/.libs
-B/cygdrive/e/Gcc/snap-bin/x86_64-unknown-cygwin/./libquadmath/.libs
-L/cygdrive/e/Gcc/snap-bin/x86_64-unknown
-cygwin/./libquadmath/.libs -o ./submodule_6.exe
lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument

plus a few more testsuite fails due to the same error, for example

FAIL: gfortran.dg/lto/20091016-1 f_lto_20091016-1_0.o-f_lto_20091016-1_0.o
link, -flto -g -fPIC -r -nostdlib

[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 #4 from Jonathan Wakely  ---
(In reply to blastrock from comment #2)
> And I was hoping for a way to disable it at runtime, recompiling
> gcc seems quite complex...

That's not possible.

[Bug c++/57699] Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #7)
> In my eyes, configuring that somewhere in gcc/config is awkward in that
> use case. Do you see my point?

No. I've read it several times and am not sure what you're saying. Whether
NO_IMPLICIT_EXTERN_C is defined is not determined by the _target architecture_
but by the _target_ i.e. the combination of architecture and OS.

But I'm confirming this, as it's still an issue in the current trunk.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[nruslan_devel at yahoo dot com]

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

--- Comment #18 from Ruslan Nikolaev  ---
(In reply to andysem from comment #17)
> I'll clarify why I think load() should be allowed to issue writes on the
> memory. According to [atomics.types.operations]/18 in N4713,
> compare_exchange_*() is a load operation if the comparison fails, yet we
> know cmpxchg (even the ones more narrow than cmpxchg16b) always writes, so
> we must assume a load operation may write. I do not find a definition of a
> "load operation" in the standard and [atomics.types.operations]/12 and 13
> avoid this term, saying that load() "Atomically returns the value pointed to
> by this." Again, it doesn't say anything about writes to the memory.
> 
> So, if compare_exchange_*() is allowed to write on failure, why load()
> shouldn't be? Either compare_exchange_*() issuing writes is a bug (in which
> case a lock-free CAS can't be implemented on x86 at all) or writes in load()
> should be allowed and the change wrt. cmpxchg16b should be reverted.

I think, there is way too much over-thinking about read-only case for 128-bit
atomics. Current solution is very confusing and not very well documented at the
very least. Correct me if I am wrong, but does current solution guarantee
address-freedom? If not, what is the motivation to support 128-bit read only
atomics? The only practical use case seems to be IPC where one process has a
read-only access. If not guaranteed for 128-bit, why even bother to support
read-only case which is a) not guaranteed to be lock-free b) works only within
a single process where it is easy to control read-only behavior.

I really prefer the way it was implemented in clang. It is only redirecting if
-mcx16 is not specified. BTW, it also provides very nice implementation for
Aarch64 which GCC is also lacking.

[Bug target/37727] NO_IMPLICIT_EXTERN_C for newlib

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to jos...@codesourcery.com from comment #1)
> Subject: Re:   New: NO_IMPLICIT_EXTERN_C for newlib
> 
> I've argued before and will argue again that NO_IMPLICIT_EXTERN_C should 
> be the default with a macro IMPLICIT_EXTERN_C defined for only those 
> targets known to need it.

Yes!

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to blastrock from comment #2)
> I think it would be nice to mention it in the documentation as it was in
> version 6. And I was hoping for a way to disable it at runtime, recompiling
> gcc seems quite complex...

That seems like their target arm-vita-eabi should have it disabled anyways. 
For all newlib targets, NO_IMPLICIT_EXTERN_C should be defined.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37727 also.

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

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Apr  5 18:43:26 2018
New Revision: 259150

URL: https://gcc.gnu.org/viewcvs?rev=259150=gcc=rev
Log:
PR target/85193
* config/i386/i386.md (define_attr "memory"): Handle rotate1 type.

testsuite/ChangeLog:

PR target/85193
* gcc.target/i386/pr85193.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr85193.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/85195] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O -fno-tree-ccp --param=sccvn-max-scc-size=10

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  5 18:35:16 2018
New Revision: 259149

URL: https://gcc.gnu.org/viewcvs?rev=259149=gcc=rev
Log:
PR middle-end/85195
* match.pd (BIT_FIELD_REF CONSTRUCTOR@0 @1 @2): Use view_convert around
CONSTRUCTOR_ELT (ctor, ...)->value.

* gcc.dg/pr85195.c: New test.

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

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

[blastrock at free dot fr]

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

--- Comment #2 from blastrock at free dot fr ---
I think it would be nice to mention it in the documentation as it was in
version 6. And I was hoping for a way to disable it at runtime, recompiling gcc
seems quite complex...

[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/82152] [7 Regression] ICE on invalid code in C++17 mode if inheriting constructors are used

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 18:27:49 2018
New Revision: 259147

URL: https://gcc.gnu.org/viewcvs?rev=259147=gcc=rev
Log:
PR c++/82152 - ICE with class deduction and inherited ctor.

* pt.c (do_class_deduction): Ignore inherited ctors.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction54.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

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

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 18:27:37 2018
New Revision: 259145

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

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

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/concepts/auto4.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 18:27:43 2018
New Revision: 259146

URL: https://gcc.gnu.org/viewcvs?rev=259146=gcc=rev
Log:
PR c++/84665 - ICE with array of empty class.

* decl2.c (cp_check_const_attributes): Use fold_non_dependent_expr.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/attr-noinline-4.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/decl2.c

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #5)
> I guess it depends on what exactly a normal subreg on lhs means.
> The documentation says:
>   When used as an lvalue, 'subreg' is a word-based accessor.
>   Storing to a 'subreg' modifies all the words of REG that
>   overlap the 'subreg', but it leaves the other words of REG
>   alone.
> but in this case, we really don't have a GPR, but rather a single much
> larger (512-bit) register.  Does it still imply that for -m32 (subreg:SI
> (reg:V32HI) 0)
> sets just the low 32 bits of the large register and doesn't modify anything
> else,
> and for -m64 the same means set low 32 bits, have the 32 bits above it
> undefined and the rest of bits unmodified?
> 

Yes, I guess so. For x86-64 "the 32 bits above" will be zero which might be
treated as undefined.

> Seems store_bit_field treats it that way, but perhaps IRA does not?

I believe IRA treats it in the same way.

LRA does not just emit

(insn 5658 4214 5812 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])
(reg:DI 0 ax [4040])) "pr85090.c":13 85 {*movdi_internal}
 (nil))
(insn 5812 5658 4219 2 (set (reg:DI 57 xmm20 [orig:422 i ] [422])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])) "pr85090.c":13
85 {*movdi_internal}
 (nil))

It emits through emit_move_insn (instead of xmm20, a pseudo is used on some LRA
sub-passes):

(insn 5812 5658 4219 2 (set (subreg:DI (reg/v:V32HI 57 xmm20 [orig:422 i ]
[422]) 0)   
(mem/c:DI (plus:DI (reg/f:DI 7 sp)  
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])) "v.i":13 85
{*movdi_internal}   
 (expr_list:REG_DEAD (reg:TI 20 frame)  
(nil))) 

and this insn exists till the very LRA end where it is changed (through
alter_subreg):

(insn 5812 5658 4219 2 (set (reg:DI 57 xmm20 [orig:422 i ] [422])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])) "pr85090.c":13
85 {*movdi_internal}
 (nil))

So LRA keeps subreg semantics.  It cannot change movdi_internal into the right
vector insn sequence.  I believe it is not LRA responsibility.

[Bug c++/85236] missing _mm256_atan2_ps

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
This is part of SVML, not a basic intrinsic.

[Bug debug/22318] debug info wrong for doubles followed by bools

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Apr  5 17:49:39 2018
New Revision: 259140

URL: https://gcc.gnu.org/viewcvs?rev=259140=gcc=rev
Log:
Use dlsym to check if libdl is needed for plugin

config/plugins.m4 has

 if test "$plugins" = "yes"; then
AC_SEARCH_LIBS([dlopen], [dl])
  fi

Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym:

[hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep " dl"
00038580 W dlclose
 U dl_iterate_phdr
0004dc50 W dlopen
 U dlsym
 U dlvsym
[hjl@gnu-tools-1 binutils-text]$

Testing dlopen for libdl leads to false negative when -fsanitize=address
is used.  It results in link failure:

../bfd/.libs/libbfd.a(plugin.o): undefined reference to symbol
'dlsym@@GLIBC_2.16'

dlsym should be used to check if libdl is needed for plugin.

PR gas/22318
* plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed.

Modified:
trunk/config/ChangeLog
trunk/config/plugins.m4

[Bug rtl-optimization/85237] New: missed optimisation opportunity for large/negative shifts

[vegard.nossum at oracle dot com]

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

Bug ID: 85237
   Summary: missed optimisation opportunity for large/negative
shifts
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
CC: segher at gcc dot gnu.org
  Target Milestone: ---

Input:

int f(int x)
{
return 100 >> (1 * (x == 1));
}

With -O3 I get:

f(int):
  cmpl $1, %edi
  movl $100, %edx
  movl $0, %eax
  cmovne %edx, %eax
  ret

However, (x == 1) must always be 0, since the shift would be too large (and
cause UB) otherwise. Clang is able to see this and always outputs:

f(int): # @f(int)
  movl $100, %eax
  retq

I believe a similar example would be simply:

int f(int x)
{
return 100 >> (INT_MAX * x);
}

where again, the only valid (non-UB) value for x is 0.

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

[robertw89 at googlemail dot com]

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

--- Comment #2 from robertw89 at googlemail dot com ---
Thanks you for your explaination :) . The compiler indeed emits the expected
code wit -funroll-loops

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

[robertw89 at googlemail dot com]

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

robertw89 at googlemail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug c++/83808] [7/8 Regression] "internal compiler error" for invalid input

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 17:17:11 2018
New Revision: 259138

URL: https://gcc.gnu.org/viewcvs?rev=259138=gcc=rev
Log:
PR c++/83808 - ICE with VLA initialization.

* typeck2.c (process_init_constructor_array): Don't require a VLA
initializer to have VLA type.

Added:
trunk/gcc/testsuite/g++.dg/ext/vla19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/80956] [7 Regression] ICE with abstract class vector

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |abstract class vector   |abstract class vector

--- Comment #9 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/80956] [7/8 Regression] ICE with abstract class vector

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Apr  5 17:08:21 2018
New Revision: 259137

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

PR c++/80956
* call.c (convert_like_real): Fail gracefully for a broken
std::initializer_list, missing a definition.

* name-lookup.c (do_pushtag): Tweak message, use %< and %>.

/testsuite
2018-04-05  Paolo Carlini  

PR c++/80956
* g++.dg/cpp0x/initlist100.C: New.
* g++.dg/cpp0x/initlist101.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist100.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist101.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85236] missing _mm256_atan2_ps

[bking at rtlogic dot com]

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

--- Comment #1 from bking at rtlogic dot com ---
Created attachment 43860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43860=edit
*.i* file

[Bug c++/85236] New: missing _mm256_atan2_ps

[bking at rtlogic dot com]

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

Bug ID: 85236
   Summary: missing _mm256_atan2_ps
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bking at rtlogic dot com
  Target Milestone: ---

The intel AVX2 intrinsic _mm256_atan2_ps is missing in 7.3.0


Below is the compiler command:

g++  -march=native -fopenmp -ffast-math -o atan2 atan2.cpp -lprofiler -v

And the output:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/localgcc730/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/gcc-7.3.0-build/../gcc-7.3.0/configure
--prefix=/usr/localgcc730 --with-tune=intel --disable-multilib --disable-nls
--disable-libsanitizer --enable-languages=c,c++,lto --enable-threads=posix
--enable-__cxa_atexit
Thread model: posix
gcc version 7.3.0 (GCC)
COLLECT_GCC_OPTIONS='-march=native' '-fopenmp' '-ffast-math' '-o' 'atan2' '-v'
'-shared-libgcc' '-pthread'
 /usr/localgcc730/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -quiet -v
-D_GNU_SOURCE -D_REENTRANT atan2.cpp -march=broadwell -mmmx -mno-3dnow -msse
-msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul
-mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-tbm
-mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase
-mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves
-mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
-mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku
-mno-rdpid --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=12288 -mtune=generic -quiet -dumpbase atan2.cpp -auxbase atan2
-version -fopenmp -ffast-math -o /tmp/ccmqqsm7.s
GNU C++14 (GCC) version 7.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0

/usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/x86_64-pc-linux-gnu

/usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward
 /usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include
 /usr/local/include
 /usr/localgcc730/include
 /usr/localgcc730/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fc95ef22dbe2a51096aba3db7cdac263
atan2.cpp: In function 'int main()':
atan2.cpp:51:21: error: '_mm256_atan2_ps' was not declared in this scope
 __m256 tanRes = _mm256_atan2_ps(A2,A1);
 ^~~
atan2.cpp:51:21: note: suggested alternative: '_mm256_and_ps'
 __m256 tanRes = _mm256_atan2_ps(A2,A1);
 ^~~
 _mm256_and_ps





Below is the output of gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/localgcc730/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/gcc-7.3.0-build/../gcc-7.3.0/configure
--prefix=/usr/localgcc730 --with-tune=intel --disable-multilib --disable-nls
--disable-libsanitizer --enable-languages=c,c++,lto --enable-threads=posix
--enable-__cxa_atexit
Thread model: posix
gcc version 7.3.0 (GCC)


I am using centOs 7.  Below is the output of "cat /etc/os-release"
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/;
BUG_REPORT_URL="https://bugs.centos.org/;

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

[Bug c++/84792] [6/7 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

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |broken typedef of a struct  |broken typedef of a struct

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/85136] [6/7/8 Regression] ICE with array as template variable

[jason at gcc dot gnu.org]

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

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

--- Comment #2 from Jason Merrill  ---
Doesn't depend on variable templates:

enum { e };

template void f()
{
  const int x[] = { [e] = 0 };
}

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

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Apr  5 17:05:03 2018
New Revision: 259136

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

PR c++/84792
* decl.c (grokdeclarator): Fix diagnostic about typedef name used
as nested-name-specifier, keep type and TREE_TYPE (decl) in sync.

/testsuite
2018-04-05  Paolo Carlini  

PR c++/84792
* g++.dg/other/pr84792-1.C: New.
* g++.dg/other/pr84792-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/pr84792-1.C
trunk/gcc/testsuite/g++.dg/other/pr84792-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug other/31852] Missing __builtin_memchr

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Oops, those last two commits are unrelated to this bug, the number refers to
https://bugs.llvm.org/show_bug.cgi?id=31852

Sorry for the noise.

[Bug other/31852] Missing __builtin_memchr

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Apr  5 16:59:13 2018
New Revision: 259135

URL: https://gcc.gnu.org/viewcvs?rev=259135=gcc=rev
Log:
Add another workaround to std::variant for Clang bug 31852

* include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE): Qualify
__get calls to avoid ADL and avoid ambiguity due to Clang bug.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[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

 CC||su at cs dot ucdavis.edu

--- Comment #6 from Jason Merrill  ---
*** Bug 81575 has been marked as a duplicate of this bug. ***

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Same issue.

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

[Bug target/85193] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1361 with -O2 -fno-tree-ccp -fno-tree-fre -mno-sse

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Apr  5 16:50:49 2018
New Revision: 259134

URL: https://gcc.gnu.org/viewcvs?rev=259134=gcc=rev
Log:
PR target/85193
* config/i386/i386.md (define_attr "memory"): Handle rotate1 type.

testsuite/ChangeLog:

PR target/85193
* gcc.target/i386/pr85193.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85193.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/16994] [meta-bug] VLA and C++

[jason at gcc dot gnu.org]

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

Bug 69487 Summary: Unexpected VLA initialization of char[] from ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69487

   What|Removed |Added

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

[Bug c++/83808] [7/8 Regression] "internal compiler error" for invalid input

[jason at gcc dot gnu.org]

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

Bug 69487 Summary: Unexpected VLA initialization of char[] from ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69487

   What|Removed |Added

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

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #6 from Jason Merrill  ---
Fixed in GCC 7.

[Bug c++/82152] [7/8 Regression] ICE on invalid code in C++17 mode if inheriting constructors are used

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 16:42:09 2018
New Revision: 259133

URL: https://gcc.gnu.org/viewcvs?rev=259133=gcc=rev
Log:
PR c++/82152 - ICE with class deduction and inherited ctor.

* pt.c (do_class_deduction): Ignore inherited ctors.

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

[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
I have a patch.

[Bug rtl-optimization/85235] New: [mips] Error: branch out of range

[mattst88 at gmail dot com]

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

Bug ID: 85235
   Summary: [mips] Error: branch out of range
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattst88 at gmail dot com
  Target Milestone: ---

Created attachment 43859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43859=edit
preprocessed (gzip'd) source file

On mips when attempting to compile cython's (cython.org) Code.c file, gcc
produces code that gas is unable to assemble, with

{standard input}:417146: Error: branch out of range
{standard input}:417161: Error: branch out of range
...

MIPS' gas supports --relax-branch which seems like it's supposed to be able to
sort this out, but it doesn't seem to.

Fails on gcc 6.4.0 and 7.3.0. Other versions untested. Totally guessing on the
Component field.

The attached Code.i demonstrates the problem with

mips64el-unknown-linux-gnu-gcc -mabi=n32 -O2 -march=loongson3a -mplt -pipe
-fno-strict-aliasing -fPIC -x c -c Code.i -o Code.o

[Bug c++/82152] [7/8 Regression] ICE on invalid code in C++17 mode if inheriting constructors are used

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 16:04:08 2018
New Revision: 259132

URL: https://gcc.gnu.org/viewcvs?rev=259132=gcc=rev
Log:
PR c++/84665 - ICE with array of empty class.

* decl2.c (cp_check_const_attributes): Use fold_non_dependent_expr.

Added:
trunk/gcc/testsuite/g++.dg/ext/attr-noinline-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug c++/83808] [7/8 Regression] "internal compiler error" for invalid input

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85228] [8 Regression] ICE with constexpr lambda in template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail|8.0 |

--- Comment #2 from Thomas Preud'homme  ---
Fixed in trunk

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Conclusion is that we still need a fix to emmintrin.h along the lines of
Steve's original two comments.  Additionally, we need to fix trunk to complain
about the out of range value, rather than quietly substituting correct code gen
that was not requested.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #4 from Dmitry Vyukov  ---
Removing these lines from runtime does not help unfortunately:

-   kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
- KASAN_ALLOCA_LEFT);

The right redzone is also somehow involved:

[   10.472896] Memory state around the buggy address:
[   10.473597]  8800768aec80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[   10.474623]  8800768aed00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[   10.475701] >8800768aed80: 00 00 00 00 00 00 00 00 02 cb cb cb cb cb cb
cb
[   10.475706]^
[   10.475716]  8800768aee00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
[   10.478809]  8800768aee80: 00 00 00 00 00 00 f1 f1 f1 f1 02 f2 f2 f2 f2
f2

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to David Binderman from comment #6)
> I wonder if changing type of static array full_costs from int to long would
> help solve the problem.
> 
> Adding vmakarov, who seems to be the author of most of this section
> of code.

I don't think this bug is important. It never results in a wrong code
generation.  It might only change the allocation cost and the cost change in
such case is insignificant.

Changing int to int64_t would hurt the compilation speed because costs arrays
can be quite big and the cost calculation is expensive. I have an experimental
branch (ira-select) which contains rewriting all this code, it might solve the
problem too.  There is a possibility that the new code will be in gcc-9.  If
the problem exists on the branch I'll work on it.

So I believe the bug should be P4 one and we can ignore it for now.

[Bug c++/85228] [8 Regression] ICE with constexpr lambda in template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 14:48:40 2018
New Revision: 259130

URL: https://gcc.gnu.org/viewcvs?rev=259130=gcc=rev
Log:
PR c++/85228 - ICE with lambda in enumerator.

* pt.c (bt_instantiate_type_proc): Don't assume
CLASSTYPE_TEMPLATE_INFO is non-null.

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

[Bug target/85234] New: missed optimisation opportunity for (~x >> n) ? a : b with n, a, b constants

[vegard.nossum at oracle dot com]

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

Bug ID: 85234
   Summary: missed optimisation opportunity for (~x >> n) ? a : b
with n, a, b constants
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
CC: segher at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Input:

int x;

int f()
{
return (~x >> 3) ? 1030355390 : 1367354703;
}

With -O3, trunk outputs:

f():
  movl x(%rip), %eax
  notl %eax
  sarl $3, %eax
  cmpl $1, %eax
  sbbl %eax, %eax
  andl $336999313, %eax
  addl $1030355390, %eax
  ret

Clang (also at -O3), however, outputs:

f(): # @f()
  cmpl $-8, x(%rip)
  movl $1030355390, %ecx # imm = 0x3D69F9BE
  movl $1367354703, %eax # imm = 0x51802D4F
  cmovbl %ecx, %eax
  retq

[Bug c++/85136] [6/7/8 Regression] ICE with array as template variable

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||dmalcolm at gcc dot gnu.org
Summary|ICE with array as template  |[6/7/8 Regression] ICE with
   |variable|array as template variable
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed on trunk, gcc-7-branch, and gcc-6-branch.

Started with r218752

[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85228] [8 Regression] ICE with constexpr lambda in template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/85227] [7/8/ Regression] ICE with structured binding of a forward declared variable

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||dmalcolm at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|ICE with structured binding |[7/8/ Regression] ICE with
   |of a forward declared   |structured binding of a
   |variable|forward declared variable
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed on trunk, and on gcc-7-branch.

Started with r242377 ("Implement P0217R3 - C++17 structured bindings")

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 5 Apr 2018, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
> 
> --- Comment #11 from rguenther at suse dot de  ---
> On Thu, 5 Apr 2018, redi at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
> > 
> > --- Comment #10 from Jonathan Wakely  ---
> > Seems simpler to just define:
> > 
> > struct __dual_ios_failure {
> >   __dual_ios_failure(std::string s, error_code e) : new_(s, e), old_(s) { }
> >   ios::failure[abi:cxx11] new_;
> >   ios::failure old_;
> > };
> > 
> > and make __throw_ios_failure() throw one of that type, and make the EH 
> > runtime
> > do the necessary adjustments to make this work:
> > 
> > __dual_ios_failure * p1;
> > 
> > try {
> >   try {
> > try {
> >   throw __dual_ios_failure("", {});
> > } catch (__dual_ios_failure& e1) {
> >   p1 = 
> >   throw;
> > }
> >   } catch (ios::failure[abi:cxx11]& e2) {
> > assert(  == >new_ );
> > throw;
> >   }
> > } catch (ios::failure& e3) {
> >   assert(  == >old_ );
> > }
> > 
> > i.e. if the catch handler is one of the ios::failure types and the actual
> > thrown exception is __dual_ios_failure then catch the member instead of the
> > object itself. The "throw;" would re-throw the original object of type
> > __dual_abi_failure, so the next handler would be able to perform the same
> > checks and adjustments.
> > 
> > This would only require magic in the EH catch routines, not a new way to
> > declare base classes.
> 
> True.  Given the issue of declaring the __dual_ios_failure type - as you
> said, you can't write it that way - it's probably going to be a
> builtin type?  In which case "massaging" the typeinfo data to make
> the code in the EH catchers less special might be easier.
> 
> Not sure, I'm not at all familiar with these areas of GCC internals.
> 
> Whatever it takes, it would be nice to fix this in a way not
> breaking pre-GCC7 nor GCC7-and-later code...

So you'd have a new internal composite type which you'd associate
with a typeinfo refering to some custom 
__cxxabiv1::__mab_class_type_info you'd then
implement the special filtering on?  (mab aka multiple ambiguous
bases)

The internal type could the still look like it was just
multiple-inherited from the two exception types?

That would leave the rest of the EH personality alone and thus
not affect runtime of other exception type propagation.

[Bug c++/85210] [7/8 Regression] ICE with broken structured binding in template

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-05
 CC||dmalcolm at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
Summary|ICE with broken structured  |[7/8 Regression] ICE with
   |binding in template |broken structured binding
   ||in template
 Ever confirmed|0   |1

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Confirmed.

On gcc-7-branch, with checking enabled, this is:

test.cc:5:8: internal compiler error: tree check: expected var_decl, have
parm_decl in cp_finish_decomp, at cp/decl.c:7354

7454  SET_DECL_DECOMPOSITION_P (d);

(gdb) p d
$1 = 

Started with r242408 ("Various C++17 decomposition fixes")

On trunk, this is:

internal compiler error: in fit_decomposition_lang_decl, at cp/lex.c:724

which started with r248748.

[Bug c++/85228] [8 Regression] ICE with constexpr lambda in template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Original testcase also fixed, now.

[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 #7 from Jason Merrill  ---
Author: jason
Date: Thu Apr  5 14:20:53 2018
New Revision: 259127

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

* pt.c (extract_locals_r): Don't record the local specs of variables
declared within the pattern.

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

[Bug c/85233] New: Incorrect -Wmaybe-uninitialized with -fpartial-inlining -finline-small-functions

[erik.carstensen at intel dot com]

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

Bug ID: 85233
   Summary: Incorrect -Wmaybe-uninitialized with
-fpartial-inlining -finline-small-functions
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erik.carstensen at intel dot com
  Target Milestone: ---

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

When compiling the attachment with
gcc -Wall -c foo.c -o foo.o -O1 -fpartial-inlining -finline-small-functions
I get the warning:
foo.c:26:11: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 c = x;
though it can be easily proven that x is not used uninitialized.

I tried this with 7.3.1 from fedora 27,
$ gcc -v
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 

I also tried some other gcc versions I had lying around. I can reproduce it in
all versions I have that support -fpartial-inlining (down to gcc 5.2.0)

While minimizing the test case I could see that the warning only seems to
happen when f is partially inlined, so a workaround is to pass
-fno-partial-inlining for affected files.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Wonder about:
--- gcc/cp/pt.c.jj  2018-04-05 15:02:40.290261785 +0200
+++ gcc/cp/pt.c 2018-04-05 15:59:07.174322871 +0200
@@ -16222,6 +16222,11 @@ tsubst_decomp_names (tree decl, tree pat
   DECL_HAS_VALUE_EXPR_P (decl2) = 0;
   SET_DECL_VALUE_EXPR (decl2, NULL_TREE);
   decl3 = tsubst (decl2, args, complain, in_decl);
+  if (!VAR_P (decl3))
+   {
+ decl = error_mark_node;
+ continue;
+   }
   SET_DECL_VALUE_EXPR (decl2, v);
   DECL_HAS_VALUE_EXPR_P (decl2) = 1;
   if (VAR_P (decl3))
but am not 100% sure if we have must have emitted an error in this case already
(perhaps add gcc_assert (errorcount);).

[Bug c++/85232] New: gcc fails to vectorize a nested simd function call

[marcin.krotkiewski at gmail dot com]

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

Bug ID: 85232
   Summary: gcc fails to vectorize a nested simd function call
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.krotkiewski at gmail dot com
  Target Milestone: ---

I'm compiling the following code using gcc version 8.0.1 20180319
(experimental) (also earlier versions), with flags "-march=haswell -O3
-ftree-vectorize -fopt-info-vec -ffast-math -fopenmp":

#pragma omp declare simd notinbranch
double fun1(double arg) __attribute__ ((noinline));
// double fun1(double arg)
// {
//   return 2.0*arg;
// }

#pragma omp declare simd notinbranch
// double fun2(double arg) __attribute__ ((noinline));
double fun2(double arg)
{
  // if statement is the cause of trouble
  if(arg < 0) return 0.;
  return 2.0*arg;
}

#pragma omp declare simd notinbranch
double test(double arg)
{
  double H = 0;
  H = 0;
  H += fun1(arg);
  H += fun2(arg); 
  return H;
}

Also here: https://godbolt.org/g/ZJmVzJ

Function test calls two other omp simd vectorized functions. fun1 is declared
here, and should be defined in a different compilation unit. fun2 is defined
here, should be inline'd, and contains an if statement on the argument.

As implemented above, gcc does not vectorize the function call to fun1. There
is a few things I have to do to arrive at a vectorized call:

1. move the definition of fun1 to the same compilation unit (uncomment in the
code above). fun1 is still noinline, so it will not be inline'd and a correct
vectorized call is issued

2. declare fun2 with attribute noinline. Then both fun1 and fun2 calls are
vectorized, but fun2 is not inlined.

The source of all trouble seems to be the if statement in fun2: if I remove it,
all works as expected.

What is the reason of this behaviour? Can I do something to avoid the problem?
I would like fun1 to be defined elsewhere, and fun2 to be inlined.

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 5 Apr 2018, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
> 
> --- Comment #10 from Jonathan Wakely  ---
> Seems simpler to just define:
> 
> struct __dual_ios_failure {
>   __dual_ios_failure(std::string s, error_code e) : new_(s, e), old_(s) { }
>   ios::failure[abi:cxx11] new_;
>   ios::failure old_;
> };
> 
> and make __throw_ios_failure() throw one of that type, and make the EH runtime
> do the necessary adjustments to make this work:
> 
> __dual_ios_failure * p1;
> 
> try {
>   try {
> try {
>   throw __dual_ios_failure("", {});
> } catch (__dual_ios_failure& e1) {
>   p1 = 
>   throw;
> }
>   } catch (ios::failure[abi:cxx11]& e2) {
> assert(  == >new_ );
> throw;
>   }
> } catch (ios::failure& e3) {
>   assert(  == >old_ );
> }
> 
> i.e. if the catch handler is one of the ios::failure types and the actual
> thrown exception is __dual_ios_failure then catch the member instead of the
> object itself. The "throw;" would re-throw the original object of type
> __dual_abi_failure, so the next handler would be able to perform the same
> checks and adjustments.
> 
> This would only require magic in the EH catch routines, not a new way to
> declare base classes.

True.  Given the issue of declaring the __dual_ios_failure type - as you
said, you can't write it that way - it's probably going to be a
builtin type?  In which case "massaging" the typeinfo data to make
the code in the EH catchers less special might be easier.

Not sure, I'm not at all familiar with these areas of GCC internals.

Whatever it takes, it would be nice to fix this in a way not
breaking pre-GCC7 nor GCC7-and-later code...

[Bug c++/85228] [8 Regression] ICE with constexpr lambda in template

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Confirmed.

Started with r251433 ("Reimplement handling of lambdas in templates.")

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #3 from Dmitry Vyukov  ---
Hummm, perhaps gcc expects that the left ASAN redzone will be within the
128-byte ABI redzone, but this becomes false with -mno-red-zone?

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #2 from Dmitry Vyukov  ---
The runtime callbacks look correct to me, and the shadow they produce also
looks reasonable: 32-byte rezone before, 32 + (32 - object size) redzone after:

 8800247b7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8800247b7200: 00 00 00 00 ca ca ca ca 02 cb cb cb cb cb cb cb
 ^
 8800247b7280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #1 from Dmitry Vyukov  ---
I am also looking at kernel callback implementation, maybe they disagree with
compiler as to what's actually passed as arguments:


/* Emitted by compiler to poison alloca()ed objects. */
void __asan_alloca_poison(unsigned long addr, size_t size)
{
size_t rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
size_t padding_size = round_up(size, KASAN_ALLOCA_REDZONE_SIZE) -
rounded_up_size;
size_t rounded_down_size = round_down(size, KASAN_SHADOW_SCALE_SIZE);

const void *left_redzone = (const void *)(addr -
KASAN_ALLOCA_REDZONE_SIZE);
const void *right_redzone = (const void *)(addr + rounded_up_size);

WARN_ON(!IS_ALIGNED(addr, KASAN_ALLOCA_REDZONE_SIZE));

kasan_unpoison_shadow((const void *)(addr + rounded_down_size),
  size - rounded_down_size);
kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
KASAN_ALLOCA_LEFT);
kasan_poison_shadow(right_redzone,
padding_size + KASAN_ALLOCA_REDZONE_SIZE,
KASAN_ALLOCA_RIGHT);
}
EXPORT_SYMBOL(__asan_alloca_poison);

/* Emitted by compiler to unpoison alloca()ed areas when the stack unwinds. */
void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom)
{
if (unlikely(!stack_top || stack_top > stack_bottom))
return;

kasan_unpoison_shadow(stack_top, stack_bottom - stack_top);
}
EXPORT_SYMBOL(__asan_allocas_unpoison);