[Bug middle-end/90923] hash_map destroys elements without constructing them

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-19
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01105.html

[Bug fortran/89103] Allow blank format items in format strings

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Jun 19 03:02:21 2019
New Revision: 272467

URL: https://gcc.gnu.org/viewcvs?rev=272467=gcc=rev
Log:
2019-06-19  Jim MacArthur  
Mark Eggleston  

PR fortran/89103
* gfortran.texi: Add -fdec-blank-format-item
* invoke.texi: Add option to list of options.
* invoke.texi: Add to section on Commas in FORMAT specifications.
* io.c (check_format): At FMT_RPAREN goto finished if
-fdec-blank-format-item otherwise set error string.
* lang.opt: Add new option.
* options.c (set_dec_flags): Add SET_BITFLAG for
flag_dec_format_defaults.

* gfortran.dg/dec_format_empty_item_1.f: New test.
* gfortran.dg/dec_format_empty_item_2.f: New test.
* gfortran.dg/dec_format_empty_item_3.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dec_format_empty_item_1.f
trunk/gcc/testsuite/gfortran.dg/dec_format_empty_item_2.f
trunk/gcc/testsuite/gfortran.dg/dec_format_empty_item_3.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/io.c
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog

[Bug target/90912] Thread-local storage not working properly when compiling code with -fPIC and optimization on Solaris

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Andrew Pinski  ---
Well GCC is producing correct code is GNU LD works with it.  Report this bug to
Sun^wOracle instead.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[glisse at gcc dot gnu.org]

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

--- Comment #42 from Marc Glisse  ---
Created attachment 46502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46502=edit
other hack

Another approach.
* lowering in an optimization pass is idiotic, it only works at -O2+, but it
shows the idea and should be easy to move anywhere.
* manually setting SSA_NAME_DEF_STMT seems strange, it probably should happen
automatically as it does for an assignment.

I think this kind of approach makes sense. It can be made to work without too
much effort, and then can be incrementally improved
0) handle vectors and complex
1) let targets replace "=g" with something nicer, say "=x" or "=xm" for SSE (we
generate nonsense for "=gx").
2) allow targets to expand the operations as they like (add an opcode?)
3) add parsing of #pragma fenv and change flag_rounding_math according to it
4) enable it as well for flag_trapping_math (and stop making that the default!)
5) add some constant folding (mpfr can tell if operations are exact or raise
any flag)
6) add other, more specific versions, for cases where we care about rounding
but not flags, or the reverse, or when we know the rounding direction (possible
in the newest C standard?), or...
etc

[Bug plugins/90924] New: lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.

[rkx1209dev at gmail dot com]

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

Bug ID: 90924
   Summary: lto-plugin/lto-plugin.c heap memory corruption due to
insufficient sanitization.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rkx1209dev at gmail dot com
  Target Milestone: ---

Created attachment 46501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46501=edit
Proof of Concept ELF binary for nm command

On several major linux distributions like ubuntu, debian... binutils uses ELF
parser from gold linker plugin,
/usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so instead of libbfd. 
I found a memory corruption bug (Heap OOB read) of gold ELF parser linked from
latest nm command(2.30). 
If input binary file has a zero value string section offset (i.e e_shstrndx ==
0.), gold ELF parser try to find string section by
simple_object_find_sections() without enough sanitization.

https://github.com/gcc-mirror/gcc/blob/6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/lto-plugin/lto-plugin.c#L1059

As a result if e_shstrndx is equal to 0, "(eor->shstrndx - 1)" at this line
cause integer overflow (a result becomes negative value (unsigned int)-1 ) 
https://github.com/gcc-mirror/gcc/blob/6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/libiberty/simple-object-elf.c#L600

and try to do out of bound access against heap memory, cause memory corruption.

On Ubuntu 18.10 with GCC 9.1.0.

PoC file is attached to this email.
Execute PoC:
nm ./memcorrupt_nm-2.30_gcc-9.1.0_gold 
Segmentation fault (core dumped)

CrashDump:
nm --plugin ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0
./memcorrupt_nm-2.30_gcc-9.1.0_gold
Core was generated by `nm --plugin
./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0 ./researc'.   
Program terminated with signal SIGSEGV, Segmentation fault. 
#0  simple_object_fetch_little_64 (buf=0x5678b4bc3640 )
at ../../libiberty/simple-object-common.h:262   
262   return (((ulong_type) buf[7] << 56)   
(gdb) bt
#0  simple_object_fetch_little_64 (buf=0x5678b4bc3640 )
at ../../libiberty/simple-object-common.h:262   
#1  0x7feb2c5b7268 in simple_object_elf_find_sections (sobj=0x5638b4bc3630,
pfn=0x7feb2c5b0930 ,  
data=0x7ffd5884ca00, err=0x7ffd5884c9f4) at
../../libiberty/simple-object-elf.c:601   
#2  0x7feb2c5b0dd5 in claim_file_handler (file=0x7ffd5884cac0,
claimed=0x7ffd5884cabc)
at ../../lto-plugin/lto-plugin.c:1025   
#3  0x7feb2c49796b in ?? () from
/usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
#4  0x7feb2c497bef in ?? () from
/usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
#5  0x7feb2c30880a in bfd_check_format_matches () from
/usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so   
#6  0x5638b4012cb0 in ?? ()
#7  0x5638b40109e6 in ?? ()
#8  0x7feb2c07f09b in __libc_start_main (main=0x5638b4010590, argc=4,
argv=0x7ffd5884ceb8, init=,
fini=, rtld_fini=, stack_end=0x7ffd5884cea8)
at ../csu/libc-start.c:308
#9  0x5638b4010a5a in ?? ()
```

Thanks
Ren

[Bug target/90912] Thread-local storage not working properly when compiling code with -fPIC and optimization on Solaris

[wpk at culm dot net]

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

--- Comment #3 from Witold Krecicki  ---
It seems to be a bad interaction between GCC and Solaris linker, with GNU ld it
works correctly on all optimization levels - gcc -v below. Unfortunately gcc
shipped with Solaris is using Solaris linker.

```
Using built-in specs.
COLLECT_GCC=/usr/gcc/9-gnuld/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/lto-wrapper
Target: x86_64-pc-solaris2.11
Configured with: ../configure --prefix=/usr/gcc/9-gnuld
--mandir=/usr/gcc/9-gnuld/share/man --bindir=/usr/gcc/9-gnuld/bin
--sbindir=/usr/gcc/9-gnuld/sbin --libdir=/usr/gcc/9-gnuld/lib
--infodir=/usr/gcc/9-gnuld/share/info --libexecdir=/usr/gcc/9-gnuld/lib
--enable-languages=c,c++,fortran,objc --enable-shared --enable-initfini-array
--disable-rpath --with-system-zlib --with-build-config=no
--with-gmp-include=/usr/include --with-mpfr-include=/usr/include
--with-gnu-ld=/usr/gnu/bin/ld --with-ld=/usr/gnu/bin/ld --with-gnu-as
--with-as=/usr/gnu/bin/as --disable-bootstrap 'BOOT_CFLAGS=-g -O2'
x86_64-pc-solaris2.11
Thread model: posix
gcc version 9.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O2' '-fPIC' '-mtune=generic' '-march=x86-64'
 /usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/cc1 -quiet -v tls-test.c
-quiet -dumpbase tls-test.c -mtune=generic -march=x86-64 -auxbase tls-test -O2
-version -fPIC -o /var/tmp//ccFCnhKb.s
GNU C17 (GCC) version 9.1.0 (x86_64-pc-solaris2.11)
compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../../x86_64-pc-solaris2.11/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/include
 /usr/gcc/9-gnuld/include
 /usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 9.1.0 (x86_64-pc-solaris2.11)
compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8d00c2a77a592f334e9eb5693e454f4c
COLLECT_GCC_OPTIONS='-v' '-O2' '-fPIC' '-mtune=generic' '-march=x86-64'
 /usr/gnu/bin/as -v -V -Qy -s --64 -o /var/tmp//cciW7WLb.o /var/tmp//ccFCnhKb.s
GNU assembler version 2.30 (x86_64-pc-solaris2.11) using BFD version (GNU
Binutils) 2.30
COMPILER_PATH=/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/:/usr/ccs/bin/
LIBRARY_PATH=/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../amd64/:/lib/amd64/:/usr/lib/amd64/:/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-fPIC' '-mtune=generic' '-march=x86-64'
 /usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/collect2 -plugin
/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/liblto_plugin.so
-plugin-opt=/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/lto-wrapper
-plugin-opt=-fresolution=/var/tmp//cce7p_6a.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
--eh-frame-hdr -V -m elf_x86_64_sol2 -Y P,/lib/amd64:/usr/lib/amd64 -Qy
/usr/lib/amd64/crt1.o
/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtp.o
/usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/lib/amd64/values-xpg6.o
/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtbegin.o
-L/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0
-L/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../amd64
-L/lib/amd64 -L/usr/lib/amd64
-L/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../..
/var/tmp//cciW7WLb.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/gcc/9-gnuld/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtend.o
/usr/lib/amd64/crtn.o
GNU ld (GNU Binutils) 2.30
  Supported emulations:
   elf_x86_64_sol2
   elf_x86_64
   elf_i386_sol2
   elf_i386_ldso
   elf_i386
   elf_iamcu
   elf_l1om
   elf_k1om
COLLECT_GCC_OPTIONS='-v' '-O2' '-fPIC' '-mtune=generic' '-march=x86-64'
```

[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #4)
> Is this PR valid or not?

Yes.  More test cases are needed, and code changes, too, to support other
clauses.

[Bug target/90922] Bad prologue generated for call0 ABI functions

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---
A fix is committed to the trunk.

[Bug target/90922] Bad prologue generated for call0 ABI functions

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Tue Jun 18 22:19:12 2019
New Revision: 272455

URL: https://gcc.gnu.org/viewcvs?rev=272455=gcc=rev
Log:
xtensa: fix PR target/90922

Stack pointer adjustment code in prologue missed a case of no
callee-saved registers and a stack frame size bigger than 128 bytes.
Handle that case.

This fixes the following gcc tests with call0 ABI:
  gcc.c-torture/execute/stdarg-2.c
  gcc.dg/torture/pr55882.c
  gcc.dg/torture/pr57569.c

2019-06-18  Max Filippov  
gcc/
* config/xtensa/xtensa.c (xtensa_expand_prologue): Add stack
pointer adjustment for the case of no callee-saved registers and
stack frame bigger than 128 bytes.


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

[Bug fortran/85221] [openacc] ICE in install_var_field, at omp-low.c:657

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:43 2019
New Revision: 272453

URL: https://gcc.gnu.org/viewcvs?rev=272453=gcc=rev
Log:
[PR85221] Set 'omp declare target', 'omp declare target link' attributes for
Fortran OpenACC 'declare'd variables

gcc/fortran/
PR fortran/85221
* trans-decl.c (add_attributes_to_decl): Handle OpenACC 'declare'
directive.
gcc/testsuite/
PR fortran/85221
* gfortran.dg/goacc/declare-3.f95: New file.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/declare-3.f95
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90921] Fortran OpenACC 'declare' directive's module handling causes duplicate data clauses

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:53 2019
New Revision: 272454

URL: https://gcc.gnu.org/viewcvs?rev=272454=gcc=rev
Log:
[PR90921] Fortran OpenACC 'declare' directive's module handling causes
duplicate data clauses

gcc/fortran/
PR fortran/90921
* trans-decl.c (finish_oacc_declare): Reset module_oacc_clauses
before scanning each namespace.
gcc/testsuite/
PR fortran/90921
* gfortran.dg/goacc/declare-3.f95: Update.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/declare-3.f95

[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:16 2019
New Revision: 272452

URL: https://gcc.gnu.org/viewcvs?rev=272452=gcc=rev
Log:
[PR90859] Document status quo for "[OMP] Mappings for VLA different depending
on 'target { c && { ! lp64 } }'"

gcc/testsuite/
PR middle-end/90859
* c-c++-common/goacc/firstprivate-mappings-1.c: Update.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/firstprivate-mappings-1.c

[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions

[tschwinge at gcc dot gnu.org]

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

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:24 2019
New Revision: 272447

URL: https://gcc.gnu.org/viewcvs?rev=272447=gcc=rev
Log:
[PR90743] Fortran 'allocatable' with OpenACC data/OpenMP 'target' 'map' clauses

Test what OpenMP 5.0 has to say on this topic.  And, do the same for OpenACC.

libgomp/
PR fortran/90743
* oacc-parallel.c (GOACC_parallel_keyed): Handle NULL mapping
case.
* testsuite/libgomp.fortran/target-allocatable-1-1.f90: New file.
* testsuite/libgomp.fortran/target-allocatable-1-2.f90: Likewise.
* testsuite/libgomp.oacc-fortran/allocatable-1-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/allocatable-1-2.f90: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-1.f90
trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-1.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-2.f90
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:14 2019
New Revision: 272446

URL: https://gcc.gnu.org/viewcvs?rev=272446=gcc=rev
Log:
[PR90861] Document status quo for OpenACC 'declare' not cleaning up for VLAs

gcc/testsuite/
PR testsuite/90861
* c-c++-common/goacc/declare-pr90861.c: New file.
libgomp/
PR testsuite/90861
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Update.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/declare-pr90861.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c

[Bug middle-end/90868] Duplicate OpenACC 'declare' directives for `extern` variables

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:04 2019
New Revision: 272445

URL: https://gcc.gnu.org/viewcvs?rev=272445=gcc=rev
Log:
[PR90868] Document status quo for duplicate OpenACC 'declare' directives for
'extern' variables

gcc/testsuite/
PR testsuite/90868
* c-c++-common/goacc/declare-1.c: Update.
* c-c++-common/goacc/declare-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/declare-1.c
trunk/gcc/testsuite/c-c++-common/goacc/declare-2.c

[Bug middle-end/90862] OpenACC 'declare' ICE when nested inside another construct

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:13:54 2019
New Revision: 272444

URL: https://gcc.gnu.org/viewcvs?rev=272444=gcc=rev
Log:
[PR90862] OpenACC 'declare' ICE when nested inside another construct

gcc/
PR middle-end/90862
* omp-low.c (check_omp_nesting_restrictions): Handle
GF_OMP_TARGET_KIND_OACC_DECLARE.
gcc/testsuite/
PR middle-end/90862
* c-c++-common/goacc/declare-1.c: Update.
* c-c++-common/goacc/declare-2.c: Likewise.
libgomp/
PR middle-end/90862
* testsuite/libgomp.oacc-c-c++-common/declare-1.c: Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/declare-1.c
trunk/gcc/testsuite/c-c++-common/goacc/declare-2.c
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-1.c

[Bug middle-end/90923] hash_map destroys elements without constructing them

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90904

--- Comment #1 from Martin Sebor  ---
The otherwise untested patch is enough to fix the test case:

diff --git a/gcc/hash-map.h b/gcc/hash-map.h
index 588dfda04fa..40e5ec5871e 100644
--- a/gcc/hash-map.h
+++ b/gcc/hash-map.h
@@ -177,7 +177,10 @@ public:
   INSERT);
   bool ins = Traits::is_empty (*e);
   if (ins)
-   e->m_key = k;
+   {
+ e->m_key = k;
+ new ((void *)>m_value) Value ();
+   }

   if (existed != NULL)
*existed = !ins;

[Bug c++/84698] ICE when using noexcept(noexcept()) declaration on global friend function of template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/84698] ICE when using noexcept(noexcept()) declaration on global friend function of template class

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun 18 21:50:51 2019
New Revision: 272443

URL: https://gcc.gnu.org/viewcvs?rev=272443=gcc=rev
Log:
PR c++/84698
* g++.dg/cpp0x/noexcept42.C: New test.

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

[Bug middle-end/90923] New: hash_map destroys elements without constructing them

[msebor at gcc dot gnu.org]

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

Bug ID: 90923
   Summary: hash_map destroys elements without constructing them
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following snippet compiles without warnings but aborts at runtime during
the destruction of the hash_map with the stack trace below.  The problem is
caused by the hash_map insertion function never invoking the element ctor but
the hash_map dtor invoking the element dtor.

See also bug 90904 for another gotcha in these basic building blocks.

struct Value
{
  Value (): ptr () { fputs (__PRETTY_FUNCTION__, stderr); }
  Value (const Value &): ptr () { fputs (__PRETTY_FUNCTION__, stderr); }
  Value& operator= (const Value &) { fputs (__PRETTY_FUNCTION__, stderr);
return *this; }
  ~Value () { fputs (__PRETTY_FUNCTION__, stderr); gcc_assert (ptr == ); }
  void *ptr;
};

void f (void)
{
  {
hash_map  m;
void *p = 
m.get_or_insert (p);
  }

Value::~Value()during GIMPLE pass: isolate-paths
...
internal compiler error: in ~Value, at gimple-ssa-isolate-paths.c:891
...
0x1e91f09 Value::~Value()
gcc/gimple-ssa-isolate-paths.c:891
0x1e936df void simple_hashmap_traits,
Value>::remove, Value>
>::hash_entry>(hash_map, Value> >::hash_entry&)
gcc/hash-map-traits.h:66
0x1e92dc3 hash_map, Value>
>::hash_entry::remove(hash_map, Value> >::hash_entry&)
gcc/hash-map.h:47
0x1e923f9 hash_table, Value> >::hash_entry, false,
xcallocator>::~hash_table()
gcc/hash-table.h:674
0x1e91f25 hash_map, Value> >::~hash_map()
gcc/hash-map.h:26
...

[Bug c++/84698] ICE when using noexcept(noexcept()) declaration on global friend function of template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r270005.  I think I'll add the testcase.

[Bug c++/83689] Internal compiler error using is_trivially_default_constructible on array of nontrivially-destructible types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed for GCC 8+, I suppose we could close it now.

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  clang 7 rejects it; newer clangs crash.  icc accepts.

[Bug fortran/87838] Segmentation fault with function pointer to contained function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #5 from kargl at gcc dot gnu.org ---
No feedback from OP.  Works for me on FreeBSD.  Closing.

[Bug c++/64329] Crash when returning reference from lambda with deduced type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
I can't reproduce the original ICE with either version.

[Bug target/90922] New: Bad prologue generated for call0 ABI functions

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 90922
   Summary: Bad prologue generated for call0 ABI functions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

call0 ABI functions that require 129 to 1024 bytes of stack frame and don't
save any incoming registers on the stack don't get stack pointer adjustment
prologue. This results in stack frame corruption in the calling functions and
wrong stack pointer upon return from the function.

Reproducer:

#include 
long x;
void
f3 (int i, ...)
{ 
  va_list aps[10];
  va_start (aps[4], i);
  x = va_arg (aps[4], long);
  va_end (aps[4]);
}

[Bug c++/64235] Internal compiler error (Segmentation fault)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
No longer ICEs, but cc1plus still accepts it.

[Bug c++/63578] ICE with may_alias and auto

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Here we're calling cplus_decl_attributes on a variable that is
undeduced_auto_decl; calling layout_type then of course crashes because the
middle end can't handle undeduced auto.

[Bug c++/71548] Invalid declaration involving template template param causes crash

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/71548] Invalid declaration involving template template param causes crash

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun 18 20:55:46 2019
New Revision: 272438

URL: https://gcc.gnu.org/viewcvs?rev=272438=gcc=rev
Log:
PR c++/71548
* g++.dg/cpp0x/variadic177.C: New test.

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

[Bug middle-end/90862] OpenACC 'declare' ICE when nested inside another construct

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-18
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Still ICEs.  Unsure if a dup of one of the existing unify bugs.

$ ./cc1plus -quiet 57527.C
57527.C: In substitution of ‘template Y::Y(X...)
[with unsigned int ...N = ]’:
57527.C:15:15:   required from here
57527.C:15:15: internal compiler error: in unify, at cp/pt.c:22209
   15 | Y y( x );
  |   ^
0xaeccfc unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22209
0xaee55f unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22553
0xaea113 try_class_unification
/home/mpolacek/src/gcc/gcc/cp/pt.c:21548
0xaee985 unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22590
0xae77f3 unify_one_argument
/home/mpolacek/src/gcc/gcc/cp/pt.c:20781
0xaeb037 unify_pack_expansion
/home/mpolacek/src/gcc/gcc/cp/pt.c:21796
0xae7e20 type_unification_real
/home/mpolacek/src/gcc/gcc/cp/pt.c:20920
0xae5f81 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:20280
0x85b35a add_template_candidate_real
/home/mpolacek/src/gcc/gcc/cp/call.c:3315
0x85b8ec add_template_candidate
/home/mpolacek/src/gcc/gcc/cp/call.c:3400
0x863c22 add_candidates
/home/mpolacek/src/gcc/gcc/cp/call.c:5724
0x85d67d build_user_type_conversion_1
/home/mpolacek/src/gcc/gcc/cp/call.c:3953
0x8561c1 implicit_conversion
/home/mpolacek/src/gcc/gcc/cp/call.c:1999
0x8554a1 reference_binding
/home/mpolacek/src/gcc/gcc/cp/call.c:1838
0x855ae3 implicit_conversion
/home/mpolacek/src/gcc/gcc/cp/call.c:1937
0x857d24 add_function_candidate
/home/mpolacek/src/gcc/gcc/cp/call.c:2330
0x863c63 add_candidates
/home/mpolacek/src/gcc/gcc/cp/call.c:5737
0x873778 build_new_method_call_1
/home/mpolacek/src/gcc/gcc/cp/call.c:9753
0x8743f2 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:9940
0x871eab build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:9366
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/90921] New: Fortran OpenACC 'declare' directive's module handling causes duplicate data clauses

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90921
   Summary: Fortran OpenACC 'declare' directive's module handling
causes duplicate data clauses
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jules at gcc dot gnu.org
  Target Milestone: ---

As reported in
.

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
When fixing the bug, let's please make sure that the dups are fixed also.

[Bug fortran/85221] [openacc] ICE in install_var_field, at omp-low.c:657

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-18
  Component|middle-end  |fortran
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Should be fixed on 10-trunk and 9-branch.

Runtime checks for the bit manipulation intrinsics will be tracked in PR90903.

[Bug c++/58836] [c++11] ICE with wrong usage of initializer list in non-type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Will be fixed by my .
 I might use the testcase though.

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||vanyacpp at gmail dot com

--- Comment #5 from Marek Polacek  ---
*** Bug 61341 has been marked as a duplicate of this bug. ***

[Bug c++/61341] ICE for variadic templates: tsubst at cp/pt.c:11313, tree check: expected class ‘expression’, have ‘type’ (integer_type)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #7 from Marek Polacek  ---
Another dup of 86426.

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

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Tue Jun 18 20:21:47 2019
New Revision: 272437

URL: https://gcc.gnu.org/viewcvs?rev=272437=gcc=rev
Log:
2019-06-18  Harald Anlauf  

Backport from mainline
2019-06-14  Harald Anlauf  

PR fortran/90577
PR fortran/90578
* trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly
distinguish logical/arithmetic shifts.
* intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA
(Fortran 2008) and LSHIFT/RSHIFT (GNU extensions).

PR fortran/90577
PR fortran/90578
* gfortran.dg/lrshift_1.f90: Adjust testcase.
* gfortran.dg/shiftalr_3.f90: New testcase.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/shiftalr_3.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/intrinsic.texi
branches/gcc-9-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/lrshift_1.f90

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Tue Jun 18 20:21:47 2019
New Revision: 272437

URL: https://gcc.gnu.org/viewcvs?rev=272437=gcc=rev
Log:
2019-06-18  Harald Anlauf  

Backport from mainline
2019-06-14  Harald Anlauf  

PR fortran/90577
PR fortran/90578
* trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly
distinguish logical/arithmetic shifts.
* intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA
(Fortran 2008) and LSHIFT/RSHIFT (GNU extensions).

PR fortran/90577
PR fortran/90578
* gfortran.dg/lrshift_1.f90: Adjust testcase.
* gfortran.dg/shiftalr_3.f90: New testcase.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/shiftalr_3.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/intrinsic.texi
branches/gcc-9-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/lrshift_1.f90

[Bug c++/71548] Invalid declaration involving template template param causes crash

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed by r243873 (though I suspect it might have been one of the preceding
revisions).  Will add the test.

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #4 from Marek Polacek  ---
*** Bug 77554 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
So we could have DSE ignore the padding bytes at the read point.  We may have
even discussed that at some point.  That results in something like this from
the gimple optimizers:

slow ()
{
  struct C D.25898;
  struct C D.29462;

;;   basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [always]  count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
  MEM  [(struct C *) + 8B] = {};
  D.25898.a = {};
  D.29462 = D.25898;
  D.25898 ={v} {CLOBBER};
  return D.29462;
;;succ:   EXIT [always]  count:1073741824 (estimated locally)

}


But that still doesn't really help.  Even if we tell DSE stores to the bytes
for C.b aren't live (they're uninitialized), then we get something like this:

slow ()
{
  struct C D.25898;
  struct C D.29462;

;;   basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [always]  count:1073741824 (estimated locally)
(FALLTHRU,EXECUTABLE)
  D.25898.a = {};
  D.29462 = D.25898;
  D.25898 ={v} {CLOBBER};
  return D.29462;
;;succ:   EXIT [always]  count:1073741824 (estimated locally)

}

WHich still isn't sufficient to get good code.

I'm not really sure what you want DSE to do here Richi :-)

[Bug c++/77554] ICE on valid C++11 code with variadic template function: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Also seems like a dup of 86426.

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

[Bug target/90912] Thread-local storage not working properly when compiling code with -fPIC and optimization on Solaris

[wpk at culm dot net]

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

--- Comment #2 from Witold Krecicki  ---
I was able to reproduce it on fresh build of gcc 9.1.0:

Using built-in specs.
COLLECT_GCC=/usr/gcc/9/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/lto-wrapper
Target: x86_64-pc-solaris2.11
Configured with: ../configure --prefix=/usr/gcc/9 --mandir=/usr/gcc/9/share/man
--bindir=/usr/gcc/9/bin --sbindir=/usr/gcc/9/sbin --libdir=/usr/gcc/9/lib
--infodir=/usr/gcc/9/share/info --libexecdir=/usr/gcc/9/lib
--enable-languages=c,c++,fortran,objc --enable-shared --enable-initfini-array
--disable-rpath --with-system-zlib --with-build-config=no
--with-gmp-include=/usr/include --with-mpfr-include=/usr/include
--without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as
--disable-bootstrap 'BOOT_CFLAGS=-g -O2' x86_64-pc-solaris2.11
Thread model: posix
gcc version 9.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/cc1 -quiet -v tls-test.c -quiet
-dumpbase tls-test.c -mtune=generic -march=x86-64 -auxbase tls-test -O3
-version -fPIC -o /var/tmp//ccDNriHa.s
GNU C17 (GCC) version 9.1.0 (x86_64-pc-solaris2.11)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../../x86_64-pc-solaris2.11/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/include
 /usr/gcc/9/include
 /usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 9.1.0 (x86_64-pc-solaris2.11)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f7f8d50a0a7d1f8b10135f1417732223
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/gnu/bin/as -v -V -Qy -s --64 -o /var/tmp//cc0akr6a.o /var/tmp//ccDNriHa.s
GNU assembler version 2.30 (x86_64-pc-solaris2.11) using BFD version (GNU
Binutils) 2.30
COMPILER_PATH=/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/:/usr/ccs/bin/
LIBRARY_PATH=/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../amd64/:/lib/amd64/:/usr/lib/amd64/:/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/collect2 -V -Y
P,/lib/amd64:/usr/lib/amd64 -Qy /usr/lib/amd64/crt1.o
/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtp.o /usr/lib/amd64/crti.o
/usr/lib/amd64/values-Xa.o /usr/lib/amd64/values-xpg6.o
/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtbegin.o
-L/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0
-L/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../../amd64 -L/lib/amd64
-L/usr/lib/amd64 -L/usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/../../..
/var/tmp//cc0akr6a.o -lgcc -z ignore -lgcc_s -z record -lc -lgcc -z ignore
-lgcc_s -z record /usr/gcc/9/lib/gcc/x86_64-pc-solaris2.11/9.1.0/crtend.o
/usr/lib/amd64/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3159
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-O3' '-mtune=generic' '-march=x86-64'

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
*** Bug 79628 has been marked as a duplicate of this bug. ***

[Bug c++/79628] ICE on invalid code in tsubst, at cp/pt.c:13499

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
Most likely a dup of 86426.  Which has a valid test.

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

[Bug c++/80667] [c++1z] ice segfault on partial specialization with non-type template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I no longer see the ICE.

[Bug c++/84822] Partial specializing template internal compiler error

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Still ICEs.

[Bug libstdc++/90920] [9/10 Regression] ABI incompatibility in std::rotate

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-18
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The problem case happens when std::rotate is compiled with the old headers and
std::__rotate is compiled with the new code, and so neither function checks for
an empty range.

Reverting the patch is easy, but that doesn't help code already compiled with
GCC 9.1, which has non-checking instantiations of std::__rotate.

[Bug libstdc++/90919] vector::iterator is constructible from a pointer

[mclow.lists at gmail dot com]

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

Marshall Clow  changed:

   What|Removed |Added

 CC||mclow.lists at gmail dot com

--- Comment #1 from Marshall Clow  ---
This code is rejected by both libc++ and MSVC, so it is not just "theoretically
non-portable"

[Bug c++/86478] Crashed on legal code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
Dup.

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

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

--- Comment #2 from Marek Polacek  ---
*** Bug 86478 has been marked as a duplicate of this bug. ***

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Will be fixed by 

[Bug c++/90170] [7/8/9/10 Regression] ICE in unify, at cp/pt.c:22209

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug libstdc++/90920] New: [9/10 Regression] ABI incompatibility in std::rotate

[redi at gcc dot gnu.org]

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

Bug ID: 90920
   Summary: [9/10 Regression] ABI incompatibility in std::rotate
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: fdumont at gcc dot gnu.org
  Target Milestone: ---

r263433 moved some checking from std::__rotate to its caller, std::rotate. It's
no longer safe to combine code compiled before and after that change:

tmp$ cat rot1.cc
#include 

namespace std {
// explicit instantiation definition to simulate the linker choosing the
// definition from this file.
template int* __rotate(int*, int*, int*, random_access_iterator_tag);
}
tmp$ cat rot2.cc
#include 

namespace std {
// explicit instantiation definition to simulate the linker choosing a
// definition from another file.
extern template int* __rotate(int*, int*, int*, random_access_iterator_tag);
}
int main()
{
  int i = 0;
  std::rotate(, , +1);
}
tmp$ /home/jwakely/gcc/9.1.0/bin/g++ -c rot1.cc
tmp$ /home/jwakely/gcc/8.3.0/bin/g++ -c rot2.cc
tmp$ /home/jwakely/gcc/9.1.0/bin/g++ rot1.o rot2.o
tmp$ ./a.out
Floating point exception (core dumped)

[Bug c++/65707] internal compiler error: in unify, at cp/pt.c:18577

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
The patch I posted today fixes this:

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #12 from Tobias Burnus  ---
I have now pulled the newest GCC trunk version - and bootstrapped into an empty
directory.

I CANNOT REPRODUCE it any more.

Either it was fixed by any of the other commits inbetween or it was an
anti-schoedinger bug, an odd interaction doing incremental builds when trying
to find the regression - or the latent bug still exists but is now hidden,
which I won't rule out as it wasn't robust against modifications of file name
and the command line.

I currently do not intent to dig into this further by trying whether going back
to an older version will bring back this bug.

[Bug libstdc++/90919] New: vector::iterator is constructible from a pointer

[redi at gcc dot gnu.org]

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

Bug ID: 90919
   Summary: vector::iterator is constructible from a pointer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This compiles:

#include 
int main()
{
  std::vector v{1, 2, 3};
  std::vector::iterator iter([0]);
}

Maybe it would be better if it didn't, it just encourages non-portable code.
The whole point of __normal_iterator is that it's not just a pointer.

[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|9.2 |10.0

[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jun 18, 2019 at 06:20:06PM +, kargl at gcc dot gnu.org wrote:
> This patch 
> 
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c   (revision 272432)
> +++ gcc/fortran/resolve.c   (working copy)
> @@ -583,6 +583,9 @@ resolve_contained_fntype (gfc_symbol *sym, gfc_namespa
>|| sym->attr.entry_master)
>  return;
> 
> +  if (!sym->result)
> +return;
> +
>/* Try to find out of what the return type is.  */
>if (sym->result->ts.type == BT_UNKNOWN && sym->result->ts.interface == 
> NULL)
>  {
> 

Passes regression testing.  I'll pack this later today.

[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
This patch 

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 272432)
+++ gcc/fortran/resolve.c   (working copy)
@@ -583,6 +583,9 @@ resolve_contained_fntype (gfc_symbol *sym, gfc_namespa
   || sym->attr.entry_master)
 return;

+  if (!sym->result)
+return;
+
   /* Try to find out of what the return type is.  */
   if (sym->result->ts.type == BT_UNKNOWN && sym->result->ts.interface == NULL)
 {

produces

% gfcx -c a.f90
a.f90:12:20:

   12 |   subroutine g(x)
  |1
Error: Type mismatch in argument 'x' (REAL(4)/INTEGER(4)) at (1)
a.f90:17:7:

   17 |use m
  |   1
   18 |integer :: x = 3
   19 |call g(x)
  |2
Error: 'g' at (1) has a type, which is not consistent with the CALL at (2)

Not sure if this is good enough.

[Bug bootstrap/90918] New: -Wreturn-local-addr in __splitstack_find in libgcc/generic-morestack.c

[msebor at gcc dot gnu.org]

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

Bug ID: 90918
   Summary: -Wreturn-local-addr in __splitstack_find in
libgcc/generic-morestack.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing an enhancement to the -Wreturn-local-addr warning I get the
following instance of it for the code in libgcc below:

/ssd/test/src/71924/libgcc/generic-morestack.c: In function
‘__splitstack_find’:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
/ssd/test/src/71924/libgcc/generic-morestack.c:853:25: note: declared here
  853 |   struct stack_segment *segment;
  | ^~~


The warning looks justified:

void *
__splitstack_find (void *segment_arg, void *sp, size_t *len,
   void **next_segment, void **next_sp,
   void **initial_sp)
{
  struct stack_segment *segment;   <<< local
  void *ret;
  char *nsp;
  ...
  else
{
  *initial_sp = __morestack_initial_sp.sp;
  segment = __morestack_current_segment;
  sp = (void *)   <<< assign address of a local to sp
  ...
  }
  ...
#ifdef __LIBGCC_STACK_GROWS_DOWNWARD__
  *len = (char *) (segment + 1) + segment->size - (char *) sp;
  ret = (void *) sp;   <<< assign sp to ret
#else
  *len = (char *) sp - (char *) (segment + 1);
  ret = (void *) (segment + 1);
#endif

  return ret;  <<< return 
}

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r270765.

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Martin Sebor from comment #6)
> With str being a local (non-reference) variable this should be diagnosed
> because of the str.D.28972._M_local_buf(12):
> 
> # _47 = PHI <_59(9), _M_local_buf(12), _59(8)>
>   str ={v} {CLOBBER};
>   return _47;

the dump above was obtained from your testcase, compiled with a slightly hacked
libstdc++

+++ basic_string.h  2019-06-18 17:40:06.435533019 +0200
@@ -214,7 +214,9 @@
   _M_set_length(size_type __n)
   {
_M_length(__n);
+   auto X = _M_data();
traits_type::assign(_M_data()[__n], _CharT());
+   if(X!=_M_data())__builtin_unreachable();
   }

   bool

+++ basic_string.tcc2019-06-18 17:38:00.755534757 +0200
@@ -221,8 +221,12 @@
  }

// Check for out_of_range and length_error exceptions.
+   auto X = _M_data();
__try
- { this->_S_copy_chars(_M_data(), __beg, __end); }
+ {
+   this->_S_copy_chars(_M_data(), __beg, __end);
+   if(X!=_M_data())__builtin_unreachable();
+ }
__catch(...)
  {
_M_dispose();

and I am really not seeing a warning. But that's probably because the
path-isolation pass is too early (from a warning PoV), the IL doesn't look that
nice at that time yet.

[Bug debug/90901] Debug information broken when compiled with gdwarf-split

[rajpal.gusain at gmail dot com]

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

--- Comment #3 from Rajpal Singh  ---
I did try with g++ 9.1.0 and I still see similar/same issue.

% g++ --version
g++ (GCC) 9.1.0


% readelf -w 

readelf: Error:  Unknown macro opcode 52 seen
readelf: Error:  Unknown macro opcode 12 seen
readelf: Error:  Unknown macro opcode 19 seen
readelf: Error:  Unknown macro opcode 11 seen
readelf: Error:  Unknown macro opcode 11 seen
readelf: Error:  Unknown macro opcode 22 seen
readelf: Error:  Unknown macro opcode 35 seen
readelf: Error:  Unknown macro opcode 2d seen
readelf: Error:  Unknown macro opcode 49 seen
readelf: Error:  Unknown macro opcode 97 seen
readelf: Error:  Unknown macro opcode 3d seen
readelf: Error:  Unknown macro opcode 13 seen
readelf: Error:  Unknown macro opcode 3b seen

[Bug debug/90901] Debug information broken when compiled with gdwarf-split

[rajpal.gusain at gmail dot com]

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

--- Comment #2 from Rajpal Singh  ---
(In reply to Richard Biener from comment #1)
> You may want to check GCC 9.1 which received some fixes for -gsplit-dwarf
> which is otherwise in a sorry and unmaintained state...

Thanks Richard for your suggestion but moving to GCC9.1 is not possible at this
point of time. It means I'll have to chuck off plan to use split-dwarf on
current project.

[Bug c++/90915] [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced along with the built-in in r266335.

[Bug debug/90914] [10 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:27153

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |debug
   Target Milestone|--- |10.0

[Bug tree-optimization/90917] Propagate constants into loads if dominated by str(n)cmp/memcmp

[david.bolvansky at gmail dot com]

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

--- Comment #1 from Dávid Bolvanský  ---
char f(void) {
  char* s = ... ;
  if (strcmp(global_s, s) == 0) return global_s[0];
  return '-';
}

-->

char f2(void) {
  char* s = ... ;
  if (strcmp(global_s, s) == 0) return s[0];
  return '-';
}

[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
With str being a local (non-reference) variable this should be diagnosed
because of the str.D.28972._M_local_buf(12):

# _47 = PHI <_59(9), _M_local_buf(12), _59(8)>
  str ={v} {CLOBBER};
  return _47;

In your example a is a reference argument but in this modified version:

  struct A { char *p; char c[13]; };

  void* f (struct A a, _Bool b)
  {
a.p = b ? a.c : (char*)__builtin_malloc (13);
__builtin_memcpy (a.p, "hello world!", 12);
a.p[12] = 0;
return a.p;
  }

and the IL:

   [local count: 354334802]:
  iftmp.0_7 = __builtin_malloc (13);

   [local count: 1073741824]:
  # iftmp.0_2 = PHI 
  a.p = iftmp.0_2;
  __builtin_memcpy (iftmp.0_2, "hello world!", 12);
  _1 = a.p;
  MEM[(char *)_1 + 12B] = 0;
  return _1;

the only challenge with detecting the bug that I see is making a record of the
rhs of the assignment to _1 = a.p (and others like that) and then checking the
prior assignment to a.p (et al.).  With that in place the "may return" warning
will trigger.

[Bug tree-optimization/90917] New: Propagate constants into loads if dominated by str(n)cmp/memcmp

[david.bolvansky at gmail dot com]

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

Bug ID: 90917
   Summary: Propagate constants into loads if dominated by
str(n)cmp/memcmp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

Motivation:

char f(char* s) {
  if (strcmp(s, "test") == 0) return s[0];
  return '-';
}

--->

char f2(char* s) {
  if (strcmp(s, "test") == 0) return 't';
  return '-';
}

[Bug inline-asm/90907] Binary crashes if both asm() and __thread are used in the same code

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
If you want intuitive asm outside of C functions, you should program
assembler code, not C.  If you insist on fighting the compiler, and the
compiler wins, don't say we didn't warn you.

[Bug c++/90916] New: [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[gs...@t-online.de]

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

Bug ID: 90916
   Summary: [10 Regression] ICE in retrieve_specialization, at
cp/pt.c:1258
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This issue hits gcc-10 and has changed before 20190505 :


$ cat z1.cc
template  struct S
{
  struct A;
  struct f A ();
};
template class S ;


$ g++-9-20190615 -c z1.cc
$
$ g++-10-20190616 -c z1.cc
z1.cc: In instantiation of 'class S':
z1.cc:6:16:   required from here
z1.cc:4:12: internal compiler error: Segmentation fault
4 |   struct f A ();
  |^
0xb933cf crash_signal
../../gcc/toplev.c:326
0x6d8f0f retrieve_specialization
../../gcc/cp/pt.c:1258
0x6f54ad tsubst_function_decl
../../gcc/cp/pt.c:12983
0x6eeeb9 tsubst_decl
../../gcc/cp/pt.c:13489
0x6e56a7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14390
0x6fda98 instantiate_class_template_1
../../gcc/cp/pt.c:11229
0x6fda98 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:11534
0x72e655 complete_type(tree_node*)
../../gcc/cp/typeck.c:139
0x6f6e7f do_type_instantiation(tree_node*, tree_node*, int)
../../gcc/cp/pt.c:23909
0x6cacf7 cp_parser_explicit_instantiation
../../gcc/cp/parser.c:17199
0x6cd271 cp_parser_declaration
../../gcc/cp/parser.c:13186
0x6cd911 cp_parser_translation_unit
../../gcc/cp/parser.c:4690
0x6cd911 c_parse_file()
../../gcc/cp/parser.c:41255
0x78c1f0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug c++/90915] New: [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[gs...@t-online.de]

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

Bug ID: 90915
   Summary: [9/10 Regression] ICE in has_attribute, at
c-family/c-attribs.c:4221
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20181118 and 20181125 :


$ cat z1.cc
struct S;
template struct T
{
  static_assert (__builtin_has_attribute (((S *) 0) -> a, packed));
};


$ g++-10-20190616 -c z1.cc
z1.cc:4:53: warning: invalid use of incomplete type 'struct S'
4 |   static_assert (__builtin_has_attribute (((S *) 0) -> a, packed));
  | ^~
z1.cc:1:8: note: forward declaration of 'struct S'
1 | struct S;
  |^
z1.cc:4:59: internal compiler error: Segmentation fault
4 |   static_assert (__builtin_has_attribute (((S *) 0) -> a, packed));
  |   ^~
0xb933cf crash_signal
../../gcc/toplev.c:326
0x7a1872 has_attribute(unsigned int, tree_node*, tree_node*, tree_node*
(*)(tree_node*))
../../gcc/c-family/c-attribs.c:4221
0x6c2d46 cp_parser_has_attribute_expression
../../gcc/cp/parser.c:8584
0x6c2d46 cp_parser_unary_expression
../../gcc/cp/parser.c:8192
0x69f43f cp_parser_cast_expression
../../gcc/cp/parser.c:9346
0x69fc12 cp_parser_binary_expression
../../gcc/cp/parser.c:9448
0x6a0989 cp_parser_assignment_expression
../../gcc/cp/parser.c:9745
0x6a037d cp_parser_constant_expression
../../gcc/cp/parser.c:10029
0x6a0662 cp_parser_static_assert
../../gcc/cp/parser.c:14449
0x6cb8bc cp_parser_member_declaration
../../gcc/cp/parser.c:24393
0x6aa58a cp_parser_member_specification_opt
../../gcc/cp/parser.c:24259
0x6aa58a cp_parser_class_specifier_1
../../gcc/cp/parser.c:23400
0x6ac181 cp_parser_class_specifier
../../gcc/cp/parser.c:23662
0x6ac181 cp_parser_type_specifier
../../gcc/cp/parser.c:17424
0x6acd64 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14120
0x6c9dc5 cp_parser_single_declaration
../../gcc/cp/parser.c:28165
0x6ca14c cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:27846
0x6ca757 cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:28094
0x6ca757 cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:28113
0x6cd2c9 cp_parser_declaration
../../gcc/cp/parser.c:13183

[Bug c++/90659] [9/10 Regression] ICE in tree_to_uhwi, at tree.h:4352/7291

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---

A modified variant :


$ cat z2.cc
template 
void foo (int n)
{
  int a[n];
  [a]{};
}
void bar ()
{
  foo (2);
}

[Bug c++/90914] New: [10 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:27153

[gs...@t-online.de]

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

Bug ID: 90914
   Summary: [10 Regression] ICE in
schedule_generic_params_dies_gen, at dwarf2out.c:27153
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190526 and 20190602 :


$ cat z1.cc
template  class A;
void f ()
{
  extern A  b;
}


$ g++-10-20190526 -c z1.cc -g
$
$ g++-10-20190616 -c z1.cc -g
during RTL pass: final
z1.cc: In function 'void f()':
z1.cc:5:1: internal compiler error: in schedule_generic_params_dies_gen, at
dwarf2out.c:27153
5 | }
  | ^
0x88dc5b schedule_generic_params_dies_gen
../../gcc/dwarf2out.c:27153
0x88dc5b gen_struct_or_union_type_die
../../gcc/dwarf2out.c:25298
0x88dc5b gen_tagged_type_die
../../gcc/dwarf2out.c:25538
0x88e1a6 gen_type_die_with_usage
../../gcc/dwarf2out.c:25733
0x88eb26 gen_type_die
../../gcc/dwarf2out.c:25787
0x88f24b modified_type_die
../../gcc/dwarf2out.c:13444
0x891f96 add_type_attribute
../../gcc/dwarf2out.c:21692
0x8a26bd gen_variable_die
../../gcc/dwarf2out.c:23947
0x88b320 gen_decl_die
../../gcc/dwarf2out.c:26479
0x8a5432 process_scope_var
../../gcc/dwarf2out.c:25940
0x8a588f decls_for_scope
../../gcc/dwarf2out.c:25966
0x887b52 gen_subprogram_die
../../gcc/dwarf2out.c:23432
0x88b1a4 gen_decl_die
../../gcc/dwarf2out.c:26396
0x88bda6 dwarf2out_decl
../../gcc/dwarf2out.c:26964
0x88c49e dwarf2out_function_decl
../../gcc/dwarf2out.c:26979
0x8f8cd9 rest_of_handle_final
../../gcc/final.c:4695
0x8f8cd9 execute
../../gcc/final.c:4737

[Bug c/90841] ICE in get_atomic_generic_size, at c-family/c-common.c:6904

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Other variants may also involve :
   __atomic_store_n
   __atomic_exchange
   __atomic_exchange_n
   __atomic_compare_exchange


Compiles smoothly with fixed size :

$ cat z3.c
int a[2];
void f()
{ __atomic_load (, , __ATOMIC_SEQ_CST); }

[Bug c++/60223] [c++11] ICE with C++11-style default template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01054.html

[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
struct A { char*p; char c[13]; };
void f(A,bool b){
  a.p=b?a.c:(char*)__builtin_malloc(13);
  __builtin_memcpy(a.p, "hello world!", 12);
  a.p[12]=0;
}

gives

  if (b_4(D) != 0)
goto ; [67.00%]
  else
goto ; [33.00%]

   [local count: 719407023]:
  iftmp.0_9 = _8(D)->c;
  goto ; [100.00%]

   [local count: 354334802]:
  iftmp.0_7 = __builtin_malloc (13);

   [local count: 1073741824]:
  # iftmp.0_2 = PHI 
  a_8(D)->p = iftmp.0_2;
  __builtin_memcpy (iftmp.0_2, "hello world!", 12);
  _1 = a_8(D)->p;
  MEM[(char *)_1 + 12B] = 0;

Note in particular that the compiler fails to notice that memcpy cannot clobber
the first field of p.

If I tweak the libstdc++ implementation to let it know that copying and writing
the final 0 do not clobber the pointer, I can get

  # _47 = PHI <_59(9), _M_local_buf(12), _59(8)>
  str ={v} {CLOBBER};
  return _47;

but that doesn't warn, although you just said that it warns for "maybe"s?

[Bug c++/90909] [10 Regression] call devirtualized to pure virtual

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
I think the below tweak of r271490 should be fine, it considers the bases only
when the fn isn't pure virtual:

Index: call.c
===
--- call.c  (revision 272410)
+++ call.c  (working copy)
@@ -8244,7 +8244,9 @@ build_over_call (struct z_candidate *cand, int fla
   /* See if the function member or the whole class type is declared
 final and the call can be devirtualized.  */
   if (DECL_FINAL_P (fn)
- || CLASSTYPE_FINAL (TREE_TYPE (argtype)))
+ || CLASSTYPE_FINAL (TYPE_METHOD_BASETYPE (TREE_TYPE (fn)))
+ || (CLASSTYPE_FINAL (TREE_TYPE (argtype))
+ && !DECL_PURE_VIRTUAL_P (fn)))
flags |= LOOKUP_NONVIRTUAL;

   /* [class.mfct.nonstatic]: If a nonstatic member function of a class

[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Somehow we end up with

(gdb) p debug_tree (maskt)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76c52b28 precision:1 min  max >
visited
def_stmt _157 = _155 & _21;
version:157>

this must be a latent issue.

[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Reproduced with -Ofast -march=znver1 -mveclibabi=svml

[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46500=edit
optimized dump file

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
CCing Jason if he has any ideas.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

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

--- Comment #74 from Damien Merenne  ---
Oh yeah, I forgot to mention it is building with -j1

[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
$ (gdb) bt
#0  fancy_abort (file=0x18cc0d0 "/home/marxin/Programming/gcc/gcc/optabs.c",
line=7341, function=0x18cc738 "maybe_gen_insn") at
/home/marxin/Programming/gcc/gcc/diagnostic.c:1614
#1  0x00d16618 in maybe_gen_insn (icode=CODE_FOR_nothing, nops=3,
ops=0x7fffd580) at /home/marxin/Programming/gcc/gcc/optabs.c:7341
#2  0x00d16a68 in maybe_expand_insn (icode=CODE_FOR_nothing, nops=3,
ops=0x7fffd580) at /home/marxin/Programming/gcc/gcc/optabs.c:7385
#3  0x00d16afc in expand_insn (icode=CODE_FOR_nothing, nops=3,
ops=0x7fffd580) at /home/marxin/Programming/gcc/gcc/optabs.c:7416
#4  0x00be03e4 in expand_mask_store_optab_fn (stmt=0x7756d7e0,
optab=maskstore_optab) at /home/marxin/Programming/gcc/gcc/internal-fn.c:2536
#5  0x00be3f18 in expand_MASK_STORE (fn=IFN_MASK_STORE,
stmt=0x7756d7e0) at /home/marxin/Programming/gcc/gcc/internal-fn.def:133
#6  0x00be5406 in expand_internal_call (fn=IFN_MASK_STORE,
stmt=0x7756d7e0) at /home/marxin/Programming/gcc/gcc/internal-fn.c:3573
#7  0x00be5431 in expand_internal_call (stmt=0x7756d7e0) at
/home/marxin/Programming/gcc/gcc/internal-fn.c:3581
#8  0x009af7f8 in expand_call_stmt (stmt=0x7756d7e0) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2638
#9  expand_gimple_stmt_1 (stmt=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3709
#10 expand_gimple_stmt (stmt=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3868
#11 0x009b5002 in expand_gimple_basic_block (bb=,
disable_tail_calls=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5908
#12 0x009b6d68 in (anonymous namespace)::pass_expand::execute
(this=, fun=0x77903000) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6531
#13 0x00d35cfa in execute_one_pass (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2473
#14 0x00d36450 in execute_pass_list_1 (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2559
#15 0x00d36489 in execute_pass_list (fn=0x77903000, pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2570
#16 0x009ec780 in cgraph_node::expand (this=) at
/home/marxin/Programming/gcc/gcc/context.h:48
#17 0x009ed71c in expand_all_functions () at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
#18 symbol_table::compile (this=0x77732100) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2683
#19 0x009eff1d in symbol_table::compile (this=0x77732100) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2861
#20 symbol_table::finalize_compilation_unit (this=0x77732100) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2861
#21 0x00e09e3d in compile_file () at
/home/marxin/Programming/gcc/gcc/toplev.c:481
#22 0x007f1938 in do_compile () at
/home/marxin/Programming/gcc/gcc/toplev.c:2209
#23 toplev::main (this=this@entry=0x7fffdabe, argc=,
argc@entry=14, argv=, argv@entry=0x7fffdbb8) at
/home/marxin/Programming/gcc/gcc/toplev.c:2344
#24 0x007f544f in main (argc=14, argv=0x7fffdbb8) at
/home/marxin/Programming/gcc/gcc/main.c:39

$ (gdb) frame 4
#4  0x00be03e4 in expand_mask_store_optab_fn (stmt=0x7756d7e0,
optab=maskstore_optab) at /home/marxin/Programming/gcc/gcc/internal-fn.c:2536
2536  expand_insn (icode, 3, ops);
(gdb) p stmt
$3 = (gcall *) 0x7756d7e0
(gdb) pgg
warning: Expression is not an assignment (and might have no effect)
# .MEM_188 = VDEF <_173>
.MASK_STORE (_485, 32B, _157, cm3_125(D));

$ (gdb) p mem
$4 = (rtx) 0x776e38e8
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(mem:SF (reg/f:DI 316 [ _484 ]) [1 MEM[base: _484, offset: 0B]+0 S4 A32])
(gdb) p mask
$5 = (rtx) 0x776e3af8
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(subreg:QI (reg:HI 489) 0)
(gdb) p reg
$6 = (rtx) 0x776c9c18
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(reg/v:SF 151 [ cm3 ])
(gdb) p type
$7 = 
(gdb) p maskt
$8 = 

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #9)
> cp_parser_jump_statement (for RID_RETURN) [...]

The tree is already different for cp_parser_identifier (called via <-
cp_parser_class_name <- cp_parser_type_name <- cp_parser_simple_type_specifier
<- cp_parser_postfix_expression <- ... <- cp_parser_jump_statement).

I think I annotated (printf debugging) all code which sets TYPE_BINFO or
TYPE_NEEDS_CONSTRUCTING - without seeing a difference. Still, the setting
differs for _Res.


[Ideas how to debug this best are welcome; as reducing it didn't work, it is
easy to get lost.]

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

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

--- Comment #73 from Jens-S. Vöckler  ---
I agree with Damien Merenne: I recently tried to build gcc 8 on High Sierra on
an APFS in various ways, and it failed every time. I used my old work-around of
creating an HFS+ partition-in-a-file to build gcc 8 within, and it did build
fine. This tells me that the symptoms described in this bug are still present
in recent sources.

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
(In reply to Hannes Hauswedell from comment #12)
> Is this resolved for GCC 8.4 now?

Not yet.

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[h2+bugs at fsfe dot org]

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

--- Comment #12 from Hannes Hauswedell  ---
Is this resolved for GCC 8.4 now?

[Bug tree-optimization/90913] [10 Regress] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||rguenth at gcc dot gnu.org
  Known to work||9.1.0
 Blocks||26163
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug debug/90900] [8/9 Regression] ICE in copy_rtx, at rtl.c:376

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |copy_rtx, at rtl.c:376  |copy_rtx, at rtl.c:376
  Known to fail|10.0|

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/90913] New: [10 Regress] ICE in maybe_gen_insn, at optabs.c:7341 since r272239

[marxin at gcc dot gnu.org]

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

Bug ID: 90913
   Summary: [10 Regress] ICE in maybe_gen_insn, at optabs.c:7341
since r272239
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46499=edit
test-case

Attached test-case (reduced from 521.wrf_r) fails:

$ gcc fice.f90 -c -march=native -Ofast
fice.f90:10:30:

   10 | OVERALL_MAIN_I_LOOP: do i=its,OLD_CLOUD_NSUBMIX_LOOP
  |  1
Warning: Deleted feature: End expression in DO loop at (1) must be integer
during RTL pass: expand
fice.f90:18:0:

   18 |ccnfact(l,m,n)=cm3
  | 
internal compiler error: in maybe_gen_insn, at optabs.c:7341
0x68f8c8 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7341
0xcf4888 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7385
0xcf4888 expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7416
0xbd1c8b expand_mask_store_optab_fn
/home/marxin/Programming/gcc/gcc/internal-fn.c:2535
0x9a6b47 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2638
0x9a6b47 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3709
0x9a6b47 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3868
0x9ac351 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5904
0x9ae0b7 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6527

[Bug tree-optimization/90911] [10 Regression] 456.hmmer regression with r272239

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
So I see

fast_algorithms.c.158t.vect:fast_algorithms.c:133:5: note:  reusing loop
version created by if conversion
fast_algorithms.c.158t.vect:fast_algorithms.c:133:5: note:  reusing loop
version created by if conversion
fast_algorithms.c.158t.vect:fast_algorithms.c:133:5: note:  reusing loop
version created by if conversion
histogram.c.158t.vect:histogram.c:702:3: note:  reusing loop version created by
if conversion

and no outer loop versioning is even attempted.

It's obviously going to be ast_algorithms.c:133 since that's the P7Viterbi
function (which now is split and distributed thus it appears three times).

Eventually the cold profile for the non-vector path hurts here.  Have to
see whether the non-vector path gets any cycles.  So this may be
vect_loop_versioning where it says

  /* ???  if-conversion uses profile_probability::always () but
 prob below is profile_probability::likely ().  */

refering to the alternate path using loop_versioning.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #72 from Jonathan Wakely  ---
(In reply to Damien Merenne from comment #71)
> enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or
> directory

That's a completely different error. That header is not part of GCC.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

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

Damien Merenne  changed:

   What|Removed |Added

 CC||dam at cosinux dot org

--- Comment #71 from Damien Merenne  ---
I can also confirm this bug is still present: MacOS High Sierra, building gcc
9.1.0 with GNU Make 3.81

Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-first/./gcc/xgcc
-B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-first/./gcc/
-B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/bin/
-B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/lib/
-isystem
/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/include
-isystem
/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/sys-include
  -fno-checking -g -O2
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/include
-L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/lib
-w -m32 -O2  -g -O2
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/include
-L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/lib
-w -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc 
-mmacosx-version-min=10.5 -pipe -fno-common -I. -I. -I../../.././gcc
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/.
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/../gcc
-I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/../include
   -o enable-execute-stack.o -MT enable-execute-stack.o -MD -MP -MF
enable-execute-stack.dep  -c enable-execute-stack.c -fvisibility=hidden
-DHIDE_EXPORTS
enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or
directory

[Bug c/90912] Thread-local storage not working properly when compiling code with -fPIC and optimization on Solaris

[wpk at culm dot net]

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

--- Comment #1 from Witold Krecicki  ---
Created attachment 46498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46498=edit
Minimal testcase