[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
this does not reproduce for me at PPC nor x86-64. Are there any compilation
farm machines that reproduce it?

[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 14 15:25:22 2016
New Revision: 232368

URL: https://gcc.gnu.org/viewcvs?rev=232368=gcc=rev
Log:
PR middle-end/68146
PR tree-optimization/69155
* tree-complex.c: Include cfganal.h.
(phis_to_revisit): New variable.
(extract_component): Add phiarg_p argument.  Assert that returned
SSA_NAME has non-NULL SSA_NAME_DEF_STMT unless phiarg_p is true.
(update_phi_components): Partly rewrite to use loop over real/imag
components instead of code duplication.  If extract_component returns
SSA_NAME with NULL SSA_NAME_DEF_STMT, store SSA_NAME_VAR or
create_tmp_reg into the PHI node instead, and mention the phi triplet
in phis_to_revisit.
(tree_lower_complex): Walk bbs in rpo order.  Adjust phis recorded
in phis_to_revisit at the end.

* gfortran.dg/pr68146.f: New test.
* gfortran.dg/pr69155.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68146.f
trunk/gcc/testsuite/gfortran.dg/pr69155.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> (In reply to vries from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > Tom, what target did you reproduce on?
> > 
> > ...
> > $ gcc -v
> > Using built-in specs.
> > COLLECT_GCC=./install/bin/gcc
> > COLLECT_LTO_WRAPPER=/scratch/vries/b3/gcc_versions/data/ref-master-16-01-08/
> > install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
> > Target: x86_64-pc-linux-gnu
> > Configured with:
> > /home/vries/gcc_versions/data/ref-master-16-01-08/src/configure
> > --prefix=/home/vries/gcc_versions/data/ref-master-16-01-08//install
> > --with-cloog=/home/vries/gcc_versions/infra
> > --with-ppl=/home/vries/gcc_versions/infra
> > --with-gmp=/home/vries/gcc_versions/infra
> > --with-mpfr=/home/vries/gcc_versions/infra
> > --with-mpc=/home/vries/gcc_versions/infra
> > --with-isl=/home/vries/gcc_versions/infra --enable-checking=yes,rtl
> > --enable-languages=c,c++,fortran,go,java,objc,obj-c++,ada
> > Thread model: posix
> > gcc version 6.0.0 20160108 (experimental) (GCC)
> > ...
> 
> $ cat /etc/issue
> Ubuntu 10.04.4 LTS
> 
> $ ld -v
> GNU ld (GNU Binutils) 2.23.51.20120829

Oops, that should be:
...
$ /usr/bin/ld -v
GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303
...

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Lauri Kasanen from comment #10)
> The gcc docs state that any version of gcc above 3.4 is supported, so this
> is still a bug.

They say to start with an existing GCC binary, not that *any* version will
work. If a particular version is buggy then you might not be able to use it, so
use a different version.

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> (In reply to Richard Biener from comment #2)
> > Tom, what target did you reproduce on?
> 
> ...
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=./install/bin/gcc
> COLLECT_LTO_WRAPPER=/scratch/vries/b3/gcc_versions/data/ref-master-16-01-08/
> install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with:
> /home/vries/gcc_versions/data/ref-master-16-01-08/src/configure
> --prefix=/home/vries/gcc_versions/data/ref-master-16-01-08//install
> --with-cloog=/home/vries/gcc_versions/infra
> --with-ppl=/home/vries/gcc_versions/infra
> --with-gmp=/home/vries/gcc_versions/infra
> --with-mpfr=/home/vries/gcc_versions/infra
> --with-mpc=/home/vries/gcc_versions/infra
> --with-isl=/home/vries/gcc_versions/infra --enable-checking=yes,rtl
> --enable-languages=c,c++,fortran,go,java,objc,obj-c++,ada
> Thread model: posix
> gcc version 6.0.0 20160108 (experimental) (GCC)
> ...

$ cat /etc/issue
Ubuntu 10.04.4 LTS

$ ld -v
GNU ld (GNU Binutils) 2.23.51.20120829

[Bug target/69275] New: ICE compiling rs6000/float-128.c

[bergner at gcc dot gnu.org]

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

Bug ID: 69275
   Summary: ICE compiling rs6000/float-128.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

With revision 232346 (ie, Mike Meissner's last IEEE128 patch), we're now seeing
the following ICE on powerpc64le-linux:


/home/bergner/gcc/build/gcc-fsf-mainline-cpu-supports-base/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-cpu-supports-base/./gcc/
-B/home/bergner/gcc/install/gcc-fsf-mainline-cpu-supports-base/powerpc64le-linux/bin/
-B/home/bergner/gcc/install/gcc-fsf-mainline-cpu-supports-base/powerpc64le-linux/lib/
-isystem
/home/bergner/gcc/install/gcc-fsf-mainline-cpu-supports-base/powerpc64le-linux/include
-isystem
/home/bergner/gcc/install/gcc-fsf-mainline-cpu-supports-base/powerpc64le-linux/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/.
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/../gcc
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/../include
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/../libdecnumber/dpd
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/../libdecnumber -DHAVE_CC_TLS 
-Wno-type-limits -mvsx -mfloat128 -mno-float128-hardware
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/soft-fp
-I/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/config/rs6000  -o
float128-ifunc.o -MT float128-ifunc.o -MD -MP -MF float128-ifunc.dep  -c
/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/config/rs6000/float128-ifunc.c
-fvisibility=hidden -DHIDE_EXPORTS
/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/config/rs6000/float128-ifunc.c:282:8:
error: ifunc is not supported on this target
 TFtype __addkf3 (TFtype, TFtype)
^~~~

/home/bergner/gcc/gcc-fsf-mainline-base/libgcc/config/rs6000/float128-ifunc.c:285:8:
error: ifunc is not supported on this target
 TFtype __subkf3 (TFtype, TFtype)
^~~~

Mike, I assume you bootstrapped using a POWER9 enabled (ie, new) binutils when
you tested the patch.  If I use an older binutils (eg, 2.24 like on our genoa
system), then we get the error above.

[Bug c++/69261] [6 Regression] Copying char arrays during constexpr evaluation does not work reliably

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Jan 14 15:32:31 2016
New Revision: 232370

URL: https://gcc.gnu.org/viewcvs?rev=232370=gcc=rev
Log:
PR c++/69261
* constexpr.c (find_array_ctor_elt): Handle splitting RANGE_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-array2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/69275] ICE compiling rs6000/float-128.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc64le-linux
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug middle-end/68146] [6 Regression] ice in gimple_stmt_nonnegative_warnv_p with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 14 15:25:22 2016
New Revision: 232368

URL: https://gcc.gnu.org/viewcvs?rev=232368=gcc=rev
Log:
PR middle-end/68146
PR tree-optimization/69155
* tree-complex.c: Include cfganal.h.
(phis_to_revisit): New variable.
(extract_component): Add phiarg_p argument.  Assert that returned
SSA_NAME has non-NULL SSA_NAME_DEF_STMT unless phiarg_p is true.
(update_phi_components): Partly rewrite to use loop over real/imag
components instead of code duplication.  If extract_component returns
SSA_NAME with NULL SSA_NAME_DEF_STMT, store SSA_NAME_VAR or
create_tmp_reg into the PHI node instead, and mention the phi triplet
in phis_to_revisit.
(tree_lower_complex): Walk bbs in rpo order.  Adjust phis recorded
in phis_to_revisit at the end.

* gfortran.dg/pr68146.f: New test.
* gfortran.dg/pr69155.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68146.f
trunk/gcc/testsuite/gfortran.dg/pr69155.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug target/68269] [5 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 regression] FAIL:  |[5 regression] FAIL:
   |gcc.dg/pr68129_1.c  |gcc.dg/pr68129_1.c
   |(internal compiler error)   |(internal compiler error)

--- Comment #9 from Jakub Jelinek  ---
Hopefully fixed on the trunk so far.

[Bug target/69275] ICE compiling rs6000/float-128.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-14
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
An explicit --enable-gnu-indirect-function during configuration works fine.

[Bug target/69275] ICE compiling rs6000/float-128.c

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
(In reply to Markus Trippelsdorf from comment #1)
> An explicit --enable-gnu-indirect-function during configuration works fine.

This seems to work for me too, using my old binutils.  I tried building with a
new binutils and no --enable-gnu-indirect-function and that still failed.

[Bug target/63890] [4.9/5/6 regression] Compiling trivial program with -O -p leads to misaligned stack

[hubicka at ucw dot cz]

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

--- Comment #25 from Jan Hubicka  ---
> Dominique, can you please test the #c9 patch with the #c22 improvement and if
> it works, submit to gcc-patches?
It would be really nice to test some bigger codebase (like bootstrap with -p),
not just
running the testsuite.

Honza

[Bug sanitizer/69276] Address sanitizer does not handle heap overflow

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> Comment on attachment 37341 [details]
> suggested patch
> 
> +  else if (is_gimple_call (stmt) && gimple_store_p (stmt)
> +&& gimple_clobber_p (stmt))
> +{
> +  asan_mem_ref r;
> +  asan_mem_ref_init (, NULL, 1);
> +
> +  r.start = gimple_call_lhs (stmt);
> +  r.access_size = int_size_in_bytes (TREE_TYPE (r.start));
> +  return has_mem_ref_been_instrumented ();
> +}
> +
> 
> This condition is never true, did you mean !gimple_clobber_p instead?
> But obviously calls are never clobbers, so there is no need to test that.

Sure, that was a typo, yeah it can be removed from the condition ;)

[Bug c++/69277] ICE (Segmentation fault) used but never defined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Looks like it started with r231665.

[Bug sanitizer/69279] New: Uncomplete documentation for -fsanitize-recovery option

[marxin at gcc dot gnu.org]

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

Bug ID: 69279
   Summary: Uncomplete documentation for -fsanitize-recovery
option
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Hello.

As I've just read documentation related to -fsanitize-recovery:

'Currently this feature only works for -fsanitize=undefined (and its suboptions
except for -fsanitize=unreachable and -fsanitize=return),
-fsanitize=float-cast-overflow, -fsanitize=float-divide-by-zero,
-fsanitize=kernel-address and -fsanitize=address. For these sanitizers error
recovery is turned on by default, except -fsanitize=address, for which this
feature is experimental.'

IIUC this tells that default option for address sanitization is
-fno-sanitize-recovery=address is default value. However, if one enables the
option, it's still not enough as:

$ tail -n3 libsanitizer/asan/asan_flags.inc 
ASAN_FLAG(bool, halt_on_error, true,
  "Crash the program after printing the first error report "
  "(WARNING: USE AT YOUR OWN RISK!)")

Thus one has to run the instrumented binary with:
ASAN_OPTIONS="halt_on_error=0" ./a.out

Does it worth for mentioning or should we just change default value of
ASAN(halt_on_error) flag?

Thanks,
Martin

[Bug c++/69261] [6 Regression] Copying char arrays during constexpr evaluation does not work reliably

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
So fixed.

[Bug rtl-optimization/57193] [4.9/5/6 Regression] suboptimal register allocation for SSE registers

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
Look in lra-coalesce, if we have code to eliminate those copies, that's where
I'd expect to find it.

[Bug c++/68936] [6 Regression] ICE: tree check: expected call_expr, have target_expr in build_min_non_dep_call_vec, at cp/tree.c:2744

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Thanks for the ping.

[Bug other/69280] New: Where did -fno-plt go?

[felix-gcc at fefe dot de]

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

Bug ID: 69280
   Summary: Where did -fno-plt go?
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

I was looking for a way to create statically linked PIE ELF binaries under
Linux.

Since these are statically linked and have no shared library, I am looking for
a way to tell gcc to not use GOT or PLT for symbol lookup. Just use PC-relative
addressing and assume all referenced symbols are local to this shared object.

When googling, I found a page in the official gcc documentation online
mentioning -fno-plt:

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

This appears to be from an older gcc version? My local gcc 5.3 does not
recognize the option.

Am I supposed to use -fvisibility now for this?

Thanks,

Felix

[Bug c/69262] Request for better array bounds warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done.

[Bug fortran/69281] New: gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp

[thomas.or...@uni-hamburg.de]

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

Bug ID: 69281
   Summary: gfortran ICE on temporary array in function call with
-fstack-arrays -fopenmp
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.or...@uni-hamburg.de
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu

Created attachment 37343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37343=edit
example code triggering the ICE

Hi, here I am again crashing the GNU Fortran compiler. The attached code gives
an ICE with gfortran from 4.8.3 to 5.3.0 (maybe earlier, too) when activating
OpenMP and stack arrays:

$ gfortran -fstack-arrays -fopenmp  -c -o
test/notest_gfortran_ice_omp_add_variable.o
.preprocessed/test/notest_gfortran_ice_omp_add_variable.f90
.preprocessed/test/notest_gfortran_ice_omp_add_variable.f90:20:0:

call midx_new(midx_counts2ranges(samples))
 ^
internal compiler error: in omp_add_variable, at gimplify.c:5644
0x8dd236 omp_add_variable
../../../src/gcc-5.3.0/gcc/gimplify.c:5642
0x8e3de8 gimplify_bind_expr
../../../src/gcc-5.3.0/gcc/gimplify.c:1108
0x8e22e9 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../src/gcc-5.3.0/gcc/gimplify.c:8297
0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../src/gcc-5.3.0/gcc/gimplify.c:5519
0x8e30d3 gimplify_and_add(tree_node*, gimple_statement_base**)
../../../src/gcc-5.3.0/gcc/gimplify.c:423
0x8e30d3 gimplify_and_return_first
../../../src/gcc-5.3.0/gcc/gimplify.c:435
0x8e30d3 gimplify_omp_parallel
../../../src/gcc-5.3.0/gcc/gimplify.c:6901
0x8e30d3 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../src/gcc-5.3.0/gcc/gimplify.c:8547
0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../src/gcc-5.3.0/gcc/gimplify.c:5519
0x8e1d3b gimplify_statement_list
../../../src/gcc-5.3.0/gcc/gimplify.c:1487
0x8e1d3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../src/gcc-5.3.0/gcc/gimplify.c:8515
0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../src/gcc-5.3.0/gcc/gimplify.c:5519
0x8e401d gimplify_bind_expr
../../../src/gcc-5.3.0/gcc/gimplify.c:1136
0x8e22e9 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../src/gcc-5.3.0/gcc/gimplify.c:8297
0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../src/gcc-5.3.0/gcc/gimplify.c:5519
0x8e46c1 gimplify_body(tree_node*, bool)
../../../src/gcc-5.3.0/gcc/gimplify.c:9234
0x8e49e7 gimplify_function_tree(tree_node*)
../../../src/gcc-5.3.0/gcc/gimplify.c:9388
0xaf7cf2 gimplify_all_functions
../../../src/gcc-5.3.0/gcc/tree-nested.c:3021
0xaf7cd7 gimplify_all_functions
../../../src/gcc-5.3.0/gcc/tree-nested.c:3023
0xaf9242 lower_nested_functions(tree_node*)
../../../src/gcc-5.3.0/gcc/tree-nested.c:3040
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Removing either of -fopenmp or -fstack-arrays prevents the issue,
as does programming around the temporary storage created for the
function call. I hope that is specific enough to point out the
code to blame.

Fun fact: I stumbled upon this after experiencing the ridiculously
small OpenMP stack size of the Intel compiler despite unlimited
stack via ulimit. Because of the random crashes caused by this, they
may switch to defaulting to heap arrays like gfortran does. But since
Fortran is about efficient numerics, if anything, I very much prefer
temporary arrays to be on the stack as I am used to from other
compilers. Calling out malloc() for 10 bytes of local storage in a
function is not funny.

Since I figured out now why my code did not work with -fstack-arrays,
I may investigate what limit gfortran has for OpenMP stacks …

[Bug fortran/69281] gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug target/68648] [4.9 Regression][ARM] ICE: fail to generate BIC(immediate) instruction

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jan 14 17:27:42 2016
New Revision: 232375

URL: https://gcc.gnu.org/viewcvs?rev=232375=gcc=rev
Log:
[ARM][4.9 backport] Fix PR target/68648

PR target/68648
* config/arm/arm.md (*andsi_iorsi3_notsi): Try to simplify
the complement of operands[3] during splitting.

* gcc.dg/torture/pr68648.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr68648.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/69272] [6 Regression] ICE: in c_builtin_function, at c/c-decl.c:4020 with -fgnu-tm

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Henderson  ---
Mine.

[Bug target/68803] gcc.vect/powerpc/20050603-3.c failures since r230167

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Do 4.9.2 and 5.3.0 actually fail the testcase?  Huh?

[Bug target/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #2 from Renlin Li  ---
This relate to the strict alignment for aarch32 target. The structure is
treated as BLKmode and will be stored in the stack first.

However, I believe that this actually can be optimized by DSE pass, which will
forward the value to the ADD operation directly eliminate the store. However,
It seems it's unable to recognize the opportunities here. 

For example the following modified test case:

struct Trivial {
short i1;
short i2;
};

int foo(Trivial t)
{
return t.i1 + t.i2;
}

The expand will emits the following code, which still stores the structure into
stack first. However, DSE can optimized it and remove insn 2.

(insn 2 4 3 2 (set (mem/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -4 [0xfffc])) [1  S4 A32])
(reg:SI 0 r0)) test.c:7 -1
 (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SI 116)
(sign_extend:SI (mem/c:HI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -4 [0xfffc])) [2 t.i1+0 S2 A32])))
test.c:8 -1
 (nil))
(insn 7 6 8 2 (set (reg:SI 117)
(sign_extend:SI (mem/c:HI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -2 [0xfffe])) [2 t.i2+0 S2 A16])))
test.c:8 -1
 (nil))
(insn 8 7 9 2 (set (reg:SI 115)
(plus:SI (reg:SI 116)
(reg:SI 117))) test.c:8 -1
 (nil))


On the other hand, if the original test case is compiled with -mabi=apcs-gnu,
it will produce exactly the same code-gen as clang does.
"-mabi=apcs-gnu" will change the target BIGGEST_ALIGNMENT macro to 32.
In this case, the structure will be treated as scalar DImode. It will no longer
stored on the stack any more. The expand will emit different code from the very
beginning.

(insn 6 3 7 2 (set (reg:SI 114)
(plus:SI (subreg:SI (reg/v:DI 113 [ t ]) 0)
(subreg:SI (reg/v:DI 113 [ t ]) 4))) new.c:8 -1
 (nil))
(insn 7 6 11 2 (set (reg:SI 112 [  ])
(reg:SI 114)) new.c:8 -1
 (nil))
(insn 11 7 12 2 (set (reg/i:SI 0 r0)
(reg:SI 112 [  ])) new.c:9 -1
 (nil))
(insn 12 11 0 2 (use (reg/i:SI 0 r0)) new.c:9 -1
 (nil))

[Bug c++/68188] Ambiguous code gets compiled successfully when class and its namespace have the same name

[ppilar11 at gmail dot com]

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

--- Comment #3 from Piotr Pilarczyk  ---
Still not fixed in 5.3.0, tested here:

https://gcc.godbolt.org/

[Bug target/68648] [4.9 Regression][ARM] ICE: fail to generate BIC(immediate) instruction

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed on all active branches.

[Bug c/69262] Request for better array bounds warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 14 17:46:25 2016
New Revision: 232376

URL: https://gcc.gnu.org/viewcvs?rev=232376=gcc=rev
Log:
PR c/69262
* c-decl.c (grokdeclarator): Provide more information for invalid
array declarations.

* gcc.dg/array-15.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/array-15.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66992] [4.9/5/6 Regression] Incorrect array subscript is above bounds warning

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
I think this is probably a dup of 59124.

[Bug middle-end/69258] Flexible arrays break TBAA

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
(In reply to jos...@codesourcery.com from comment #5)
> I don't see a need for these different structures to be able to alias.  
> (Flexible array members do need to be able to alias static storage, in the 
> case where that static storage was declared with the structure type with 
> the flexible array member and the GNU C extension of initializing such 
> flexible array members was used.)

Ok, that works.  Phew.  Not sure if it is a solution for the Fortran FE
issue which wants to construct Xflex with a specific size on the stack
(it's the array descriptor with a known dimensionality).  I remember that
GNU C extension poses some interesting effects on the ME (inconsistent
TYPE_SIZE / DECL_SIZE at least).

extern void abort (void);

struct Xflex { int n; int a[]; };
struct Xflex x = { 1, { 1, 2, 3, 4, 5, 6, 7 } };

int __attribute__((noinline,noclone))
foo (struct Xflex *f)
{
  x.a[6] = 1;
  f->a[6] = 2;
  return x.a[6];
}

int __attribute__((noinline,noclone))
bar (struct Xflex *f)
{
  f->a[6] = 2;
  x.a[6] = 1;
  return f->a[6];
}

int main()
{
  if (foo ((struct Xflex *)) != 2)
abort ();
  if (bar ((struct Xflex *)) != 1)
abort ();
  return 0;
}

[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
With __builtin_omp_get_num_threads (); in the body instead and -fopenmp instead
of -fsanitize=shift it works, so there must be some lto-opts.c or whatever
magic that makes that work for other options.
Now, for the sanitizers, what we need to arrange (but not sure how to do that
exactly) is for the builtins that if any of the source files being read had
non-zero:
  (flag_sanitize & (SANITIZE_ADDRESS | SANITIZE_THREAD \
| SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT) \
   || flag_sanitize_coverage))
then the sanitizer builtins will be also enabled for LTO (either by arranging
the options so that the condition matches, or by calling
initialize_sanitizer_builtins), and also that the sanopt pass will be run.
ubsan is special in that the various instrumentations happen at various passes,
some happen at various stages, some instrumentation is done in the FEs, some is
done during genericization or gimplification, others in the ubsan pass, and yet
others even later (e.g. __builtin_unreachable instrumentation).
Unlike that, address or thread sanitization are always done post-IPA.
Thus, perhaps best would be if lto-opts.c or whatever arranged that if any of
the input sources had
flag_sanitize & (SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT)
then flag_sanitize |= SANITIZE_SHIFT (as an example of FE only handled
sanitization), this would cause both the builtins being available and the
sanopt pass be performed, but nothing else.

Also, makes me wonder what happens (if the inliner allows that) to inline ubsan
sanitized function into no_sanitize_undefined function, whether that won't
leave some partly but not fully lowered ubsan stuff in there.

CCing Honza/Richard on the LTO options handling stuff, and Marek because this
is ubsan stuff.

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

[Bug rtl-optimization/69032] [5/6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
The linked page from comment #2 mentions a discussion about this issue which
I'm unable to find.  Any hints where it is?

Anyway, we've looked into it, and it seems that this bit of code generated a
duplicate DIE:

  char a; 
  char * _Atomic restrict h; 
  char * _Atomic i; 

When handling "h", the algorithm in
dwarf2out.c:get_nearest_type_subqualifiers() finds "char *" as the nearest
existing type.  Then the for-loop in modified_type_die (line 11254) generates
an "intermediate" DIE for "char * _Atomic", and the required DIE for "char *
_Atomic restrict".  Eventually, only the latter one is linked to it's type with
"equate_type_number_to_die()", but the intermediate type is not.

When the code handles "i", and tries to lookup an existing DIE for "char *
_Atomic" (line 11199) it does not find the "intermediate" DIE and generates
another one.  This is the additional "DW_TAG_atomic" that makes the test case
fail.

Without looking at the patches that cause this, I believe that with the "early
debug" stuff the DIEs are now generated before the list of used types is
available to the loop in get_nearest_type_subqualifiers:

  for (t = TYPE_MAIN_VARIANT (type); t && best_rank < max_rank; 
 t = TYPE_NEXT_VARIANT (t))

It's probably just called earlier now.  So, the algorithm to eliminate
duplicate type DIEs does not work because it requires a complete and correct
list of used types.

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Martin Sebor from comment #4)
> Confirmed on powerpc64le:
> 
> $ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O3 -S -Wall -Wextra
> -Wpedantic -mcpu=power8 -o/dev/stdout
> /src/gcc/trunk/gcc/testsuite/gcc.target/powerpc/pr60203.c
>   .file   "pr60203.c"
>   .machine power8
>   .abiversion 2
>   .section".toc","aw"
>   .section".text"
>   .align 2
>   .p2align 4,,15
>   .globl pack
>   .type   pack, @function
> pack:
>   xxpermdi 0,2,1,0
>   addi 9,1,-16
>   xxpermdi 0,0,0,2
>   stxvd2x 0,0,9
>   lfd 1,-16(1)
>   lfd 2,-8(1)
>   blr
>   .long 0
>   .byte 0,0,0,0,0,0,0,0
>   .size   pack,.-pack
>   .align 2
>   .p2align 4,,15
>   .globl unpack_0
>   .type   unpack_0, @function
> unpack_0:
>   blr
>   .long 0
>   .byte 0,0,0,0,0,0,0,0
>   .size   unpack_0,.-unpack_0
>   .align 2
>   .p2align 4,,15
>   .globl unpack_1
>   .type   unpack_1, @function
> unpack_1:
>   fmr 1,2
>   blr
>   .long 0
>   .byte 0,0,0,0,0,0,0,0
>   .size   unpack_1,.-unpack_1
>   .ident  "GCC: (GNU) 6.0.0 20160113 (experimental)"
>   .section.note.GNU-stack,"",@progbits

Can you properly bisect it then?  Still can't reproduce with a cross from
x86_64.

Does on native .0341.fre properly contain just

pack (double a, double aa)
{
  double u$d$0;
  union u_ld u;

  :
  u.d[1] = aa_4(D);
  u ={v} {CLOBBER};
  return a_2(D);

}

or do we have some odd host dependency in early opts until here?

[Bug regression/67415] [5/6 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #7 from Nick Clifton  ---
Is this bug still reproducible ?  I tried today but could not make it happen...

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
There were fixes in that area, I assume this works now.

[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.0 |---
Summary|[6 Regression] ICE: in  |ICE: in contains_point, at
   |contains_point, at  |diagnostic-show-locus.c:340
   |diagnostic-show-locus.c:340 |after error
   |after error |

--- Comment #13 from Richard Biener  ---
Removing the regression marker then.

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Let's just assume that.

[Bug tree-optimization/69160] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1436

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Yes.

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

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

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

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
It's a bogus detected double reduction.

[Bug middle-end/46555] [4.9/5/6 Regression] PHI RTL expansion leads to CSiBE regression

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The idea is to add forwarder blocks here.  Of course doing this too
aggressively may be bad, not sure (extra jumps instead of extra copies). 
Eventually the
targets want some control on this.

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-14
 CC||vehre at gcc dot gnu.org
  Known to work||4.9.3, 6.0
Summary|Sourced allocation calls|[5 Regression] Sourced
   |function twice  |allocation calls function
   ||twice
 Ever confirmed|0   |1
  Known to fail||5.3.0

--- Comment #1 from Dominique d'Humieres  ---
> I believe this may gave been fixed in 6.0, but 5.3 seems to still have the 
> problem.

Likely fixed on trunk by revision r229294. The function is called only once
with 4.8 and 4.9 and up to revision r221412, but called twice with r221464
(+patches), likely r221436.

[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/69261] [6 Regression] Copying char arrays during constexpr evaluation does not work reliably

[jens.auer at cgi dot com]

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

--- Comment #4 from Jens Auer  ---
It produces the correct results if you change foo to not use constexpr:

void foo()
{
   auto const s1 = s( "bla" );
   auto const s2 = s( "blu" );

   string_constexpr<7> const s1s2 = concat(s1,s2);
   auto constexpr c = concat("bla", "blu");
   std::cout << s1.data << std::endl << s2.data << std::endl << s1s2.data <<
std::endl << c << std::endl;
}

$ ./a.out 
bla
blu
blablu
blablu

[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
There are several approaches to fix the problem:

1) An "Intermediate" DIE is generated if the corresponding type has not yet
been recorded.  When creating the DIE also generate the type.  This may lead to
unused types in the list.

2) Like 1, but record the new types for "intermediate" DIEs in a separate place
so that they are not visible to the remaining code.  When the type is finally
generated, "promote" it to the real type list.

3) Store the "intermediate" DIEs in a hash table (or some other structure).  If
lookup_type_die() fails, search through the hash table for a DIE describing the
type at hand.  To do this, it is necessary to generate a unique key from a
given type (for lookup in the table).  It is also necessary to generate the
same key from a given DIE (to store a DIE without a type in the table).  (Is
the "signature" in a DIE any good for this?)  May be expensive.

4) When lookup_type_die() fails, any relevant "intermediate" DIEs have been
generated for existing types whose qualifiers are a superset of the current
type.  So, get a list of such types and recurse over all existing DIEs for
these types and check whether one of them is the one we're looking for.  May be
expensive.

Any comments or alternative solutions?

[Bug target/69264] [4.9/5 regression] ICE when building spidermonkey w/-maltivec -O3: rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:4350

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |5.3.0
   Target Milestone|--- |4.9.4

[Bug c++/69263] [6 Regression] internal compiler error: in cxx_eval_store_expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/54896] optimization slowness on large basic blocks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
  Known to fail||4.9.3, 5.3.0

--- Comment #11 from Richard Biener  ---
(In reply to Bernd Schmidt from comment #10)
> This no longer seems reproducible with current trunk. The testcase takes
> about 18 seconds to compile with -O3 on my machine, with no time spent in
> slp-vect.
> 
> Did those patches make it into 4.9?

No, we eliminate the write-only variable now as well.

Move 'Data' into global scope and make it non-static and it will
still reproduce with GCC 5.

I fixed it with GCC 6 it seems.

With checking enabled I see with -O3 -fno-checking (and the above static
var issue "fixed"):

 alias stmt walking  :  27.93 (34%) usr   0.12 (22%) sys  28.18 (34%) wall 
 0 kB ( 0%) ggc
 tree DSE:   8.99 (11%) usr   0.00 ( 0%) sys   8.99 (11%) wall 
 0 kB ( 0%) ggc
 CSE :   7.60 ( 9%) usr   0.01 ( 2%) sys   7.62 ( 9%) wall 
 16382 kB ( 5%) ggc
 CSE 2   :  12.55 (15%) usr   0.00 ( 0%) sys  12.57 (15%) wall 
 0 kB ( 0%) ggc
 reload CSE regs :  17.34 (21%) usr   0.00 ( 0%) sys  17.37 (21%) wall 
  4687 kB ( 1%) ggc
 TOTAL :  81.29 0.5481.91
315199 kB

of course there's still things to speed up here, -O0 takes 1s, -Og 26s and
-O1 50s, -O2+ run into the above ~80s.

[Bug c++/69263] [6 Regression] internal compiler error: in cxx_eval_store_expression

[mpolacek at gcc dot gnu.org]

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

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  ---
Let me have a crack at this.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Well, this is a P1, so it has to be solved.  If the problem with the patch is
only in the powerpc64 add/sub carry patterns, perhaps they can be made more
flexible, plus is commutative.
Now, looking at the i?86 carry patterns, the carry operand is there in the
nested plus instead, and e.g. aarch64 seems to have a wide set of alternatives
(although there is a small difference in that the carry in that case is not a
register, but GEU) - they have add3_carryin where it is (carry + (op1 +
op2)), then *add3_carryin_alt1, where it is ((op1 + op2) + carry) and
*add3_carryin_alt2 where there is ((carry + op1) + op2) and
*add3_carryin_alt3 where there is ((carry + op2) + op1).  The last one
really surprises me, as both op1 and op2 have the same predicate/constraint, so
IMHO alt2 and alt3 are the same thing.  But ((op1 + carry) + op2) is missing
then.
For the case when the carry flag is a register, and if the RTL simplification
always puts nested plus first, it would be just about ((op1 + op2) + carry),
((carry + op1) + op2) or ((op1 + carry) + op2).  Or you could have 3 input
operands, use special predicate for them (which would allow either
gpc_reg_operand or CA_REGNO operand), and then just in insn condition require
that exactly one of the operands is the CA_REGNO and the others are not.
Would be nice to bring some consistency in between the backends in this.

[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
(In reply to Michael Collison from comment #8)
> Hi Richard,
> 
> I tried this with trunk and was unable to generate the vld3. What vectorizer
> options did you use?

Ah, I just assumed it was fixed because the patch for PR68707 was checked in.
But that conditions the "fix" on the SLP needing permutations which doesn't
trigger here.

Let's re-open then.

As asked in that other PR the question is if vld3/std3 is really cheaper
(it's definitely smaller code).

[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 14 Jan 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69254
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||hubicka at gcc dot gnu.org,
>||jakub at gcc dot gnu.org,
>||mpolacek at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
> 
> --- Comment #9 from Jakub Jelinek  ---
> With __builtin_omp_get_num_threads (); in the body instead and -fopenmp 
> instead
> of -fsanitize=shift it works, so there must be some lto-opts.c or whatever
> magic that makes that work for other options.
> Now, for the sanitizers, what we need to arrange (but not sure how to do that
> exactly) is for the builtins that if any of the source files being read had
> non-zero:
>   (flag_sanitize & (SANITIZE_ADDRESS | SANITIZE_THREAD \
> | SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT) \
>|| flag_sanitize_coverage))
> then the sanitizer builtins will be also enabled for LTO (either by arranging
> the options so that the condition matches, or by calling
> initialize_sanitizer_builtins), and also that the sanopt pass will be run.
> ubsan is special in that the various instrumentations happen at various 
> passes,
> some happen at various stages, some instrumentation is done in the FEs, some 
> is
> done during genericization or gimplification, others in the ubsan pass, and 
> yet
> others even later (e.g. __builtin_unreachable instrumentation).
> Unlike that, address or thread sanitization are always done post-IPA.
> Thus, perhaps best would be if lto-opts.c or whatever arranged that if any of
> the input sources had
> flag_sanitize & (SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT)
> then flag_sanitize |= SANITIZE_SHIFT (as an example of FE only handled
> sanitization), this would cause both the builtins being available and the
> sanopt pass be performed, but nothing else.
> 
> Also, makes me wonder what happens (if the inliner allows that) to inline 
> ubsan
> sanitized function into no_sanitize_undefined function, whether that won't
> leave some partly but not fully lowered ubsan stuff in there.
> 
> CCing Honza/Richard on the LTO options handling stuff, and Marek because this
> is ubsan stuff.

As all the -fsanitize stuff is not suitable for the optimize attribute
we need to arrange for some "sanity" across input TUs and properly
compute a link-time sensible value (if possible).  This is usually
done in lto-wrapper.c merge_and_complain.  lto-opts.c should already
stream the input TU flags into the LTO_opts section.

You probably know better what sanitize options can be combined
in which way and what link flag setting is required, thus leaving
to you or Marek to figure out what to do in lto-wrapper.

[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/67373] Can't compile gcc snapshot for avr target with mingw

[jj at stusta dot net]

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

Jonas Jelten  changed:

   What|Removed |Added

 CC||jj at stusta dot net

--- Comment #3 from Jonas Jelten  ---
I got the same problem:

avr-gcc -mmcu=atmega8 -O3 -T /usr/lib64/binutils/avr/2.25.1/ldscripts/avr4.xn 
-Wl,-Map=blingbling.map blingbling.o -o blingbling.elf
/usr/libexec/gcc/avr/ld: cannot find crtatmega8.o: No such file or directory
/usr/libexec/gcc/avr/ld: cannot find -latmega8
collect2: error: ld returned 1 exit status
...

The -T option was required so gcc finds the linker script, without it, it
crashes even earlier:

avr-gcc -mmcu=atmega8 -O3  -Wl,-Map=blingbling.map blingbling.o -o
blingbling.elf
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr4.xn: No
such file or directory
collect2: error: ld returned 1 exit status

Any idea how to fix that?

[Bug c++/68789] [5/6 Regression] ICE in tsubst_copy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Priority|P3  |P2

[Bug c++/68782] [6 regression] bad reference member formed with constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de  ---
On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> 
> --- Comment #33 from Joshua Kinard  ---
> The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
> (Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from building,
> and it ended up completing.  Difference between that script (which builds
> inside a chroot) is I used saner CFLAGS.
> 
> The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
> CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
> -fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
> LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"
> 
> So I'll look at dropping one flag at a time, along with trimming LDFLAGS, and
> see if I can pin down which one causes ./genmatch --gimple to segfault 
on N32.

-fforce-addr is a no-op and -fivopts is enabled at -O2 by default, so
you can omit those without testing.

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|unknown |6.0

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-solaris
   Priority|P3  |P1
 CC||vries at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Works for me but https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01237.html
still has it.

Maybe some as feature stuff?  Tom, what target did you reproduce on?

[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37335|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Created attachment 37340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37340=edit
gcc6-pr69155.patch

Untested fix.

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Hi,

(In reply to Lauri Kasanen from comment #6)
> Here's more details on my system.
> 
> Host gcc: 4.2.2
> Host binutils: 2.25.1
> m68k binutils: 2.24
> 
> I used make -j13, but a parallel build shouldn't affect things.

Probably not, I used -j8.

> I doubt the host gcc version is at fault either, given the function
> was passed NULL.

Well, gcc is now written in C++ and 4.2.2 might have quite a few bugs
in this regard so I would not completely rule it out.  

> I can try the latest 5 branch later on if you think it'd be useful?

Well, if you can't reproduce it there then the bug was fixed :-)

> I have no ccache or other complications like that.

I suggest that you try to replicate my steps outlined in comment #5
first.  If you can't reproduce the error that way, then we need to
look at differences in how I and you build stuff.  If it still fails,
then I would suggest trying a fresh checkout from the git branch and
finally trying a newer host compiler.

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/69030] [6 Regression] ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 Target|x86_64-linux-gnu (-m32) |i?86-*-*
   Priority|P3  |P1
  Component|target  |rtl-optimization

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Tom, what target did you reproduce on?

...
$ gcc -v
Using built-in specs.
COLLECT_GCC=./install/bin/gcc
COLLECT_LTO_WRAPPER=/scratch/vries/b3/gcc_versions/data/ref-master-16-01-08/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/home/vries/gcc_versions/data/ref-master-16-01-08/src/configure
--prefix=/home/vries/gcc_versions/data/ref-master-16-01-08//install
--with-cloog=/home/vries/gcc_versions/infra
--with-ppl=/home/vries/gcc_versions/infra
--with-gmp=/home/vries/gcc_versions/infra
--with-mpfr=/home/vries/gcc_versions/infra
--with-mpc=/home/vries/gcc_versions/infra
--with-isl=/home/vries/gcc_versions/infra --enable-checking=yes,rtl
--enable-languages=c,c++,fortran,go,java,objc,obj-c++,ada
Thread model: posix
gcc version 6.0.0 20160108 (experimental) (GCC)
...

[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P1

--- Comment #6 from Richard Biener  ---
Let's keep looking a bit but eventually downgrade again.

[Bug c++/69098] [6.0 regression] Member function pointer template flagged with 'is not a function template'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|unknown |6.0

[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[cand at gmx dot com]

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

--- Comment #8 from Lauri Kasanen  ---
Today's gcc 5 branch, git 4e07f8a1b79f5e or svn r232358, still fails.

/tmp/gccbuild/./gcc/xgcc -B/tmp/gccbuild/./gcc/ -B/tmp/tmpgcc/m68k-elf/bin/
-B/tmp/tmpgcc/m68k-elf/lib/ -isystem /tmp/tmpgcc/m68k-elf/include -isystem
/tmp/tmpgcc/m68k-elf/sys-include-g -O2 -mcpu=68000 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-git/libgcc
-I../../../../gcc-git/libgcc/. -I../../../../gcc-git/libgcc/../gcc
-I../../../../gcc-git/libgcc/../include-o unwind-dw2.o -MT unwind-dw2.o -MD
-MP -MF unwind-dw2.dep -fexceptions -c ../../../../gcc-git/libgcc/unwind-dw2.c
-fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-git/libgcc/unwind-dw2.c: In function '_Unwind_RaiseException':
../../../../gcc-git/libgcc/unwind-dw2.c:1695:0: internal compiler error:
Segmentation fault

 ^
0x8d1d1f crash_signal
../../gcc-git/gcc/toplev.c:383
0x778ad2 get_place_in_agg_contents_list
../../gcc-git/gcc/ipa-prop.c:1400
0x778ad2 determine_locally_known_aggregate_parts
../../gcc-git/gcc/ipa-prop.c:1571
0x780d70 ipa_compute_jump_functions_for_edge
../../gcc-git/gcc/ipa-prop.c:1757
0x78161c ipa_compute_jump_functions_for_bb
../../gcc-git/gcc/ipa-prop.c:1785
0x78161c analysis_dom_walker::before_dom_children(basic_block_def*)
../../gcc-git/gcc/ipa-prop.c:2299
0xb8f804 dom_walker::walk(basic_block_def*)
../../gcc-git/gcc/domwalk.c:188
0x78051f ipa_analyze_node(cgraph_node*)
../../gcc-git/gcc/ipa-prop.c:2355
0xbc2d73 ipcp_generate_summary
../../gcc-git/gcc/ipa-cp.c:4534
0x8318ae execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc-git/gcc/passes.c:2156
0x5eb98f ipa_passes
../../gcc-git/gcc/cgraphunit.c:2197
0x5eb98f symbol_table::compile()
../../gcc-git/gcc/cgraphunit.c:2313
0x5ec93c symbol_table::finalize_compilation_unit()
../../gcc-git/gcc/cgraphunit.c:2462
0x4f63c2 c_write_global_declarations()
../../gcc-git/gcc/c/c-decl.c:10822
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/69126] [6 regression] _Pragma does not apply if part of a macro

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/68698] [6 regression] FAIL: gcc.target/i386/avx512vl-vmovap[sd]-1.c

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
Dup.

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

[Bug target/69198] [6 Regression] FAIL: gcc.target/i386/avx512vl-vmovaps-1.c scan-assembler-times vmovaps[ \\t]+[^{\n]*%xmm[0-9]+[^\n]*\\){%k[1-7]}(?:\n|[ \\t]+#) 1

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
*** Bug 68698 has been marked as a duplicate of this bug. ***

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[cand at gmx dot com]

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

--- Comment #10 from Lauri Kasanen  ---
When using gcc 5.2 as the host compiler, there is no crash.

The gcc docs state that any version of gcc above 3.4 is supported, so this is
still a bug.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
Also CentOS 5.11 with GNU ld version 2.17.50.0.6-26.el5 20061020.

[Bug target/68648] [4.9 Regression][ARM] ICE: fail to generate BIC(immediate) instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||5.4.0, 6.0
Summary|[4.9/5/6 Regression][ARM]   |[4.9 Regression][ARM] ICE:
   |ICE: fail to generate   |fail to generate
   |BIC(immediate) instruction  |BIC(immediate) instruction

[Bug ipa/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/68698] [6 regression] FAIL: gcc.target/i386/avx512vl-vmovap[sd]-1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #8 from Richard Biener  ---
May want to decide to give up later (INVALID, expected false positive)

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Nick Clifton from comment #3)
> The patch checked in fixes this PR.

I think this still needs a backport to GCC 5 though

[Bug lto/69271] New: LTO drops weak binding from aliases

[nsz at gcc dot gnu.org]

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

Bug ID: 69271
   Summary: LTO drops weak binding from aliases
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

i guess it is related to bug 67548
but it happens without -r now.

void foo(void) {}
extern void foo_alias(void) __attribute__((weak, alias("foo")));
int bar = 0;
extern int bar_alias __attribute__((weak, alias("bar")));

compiled as

gcc -shared -fPIC -flto -o foo.so foo.c

$ readelf --dyn-sym -W foo.so |grep foo
 8: 0640 6 FUNCGLOBAL DEFAULT   10 foo_alias
 9: 0640 6 FUNCGLOBAL DEFAULT   10 foo
$ readelf --dyn-sym -W foo.so |grep bar
 4: 002008cc 4 OBJECT  GLOBAL DEFAULT   21 bar
 6: 002008cc 4 OBJECT  GLOBAL DEFAULT   21 bar_alias

without -flto i get the expected

$ readelf --dyn-sym -W foo.so |grep foo
 8: 0640 7 FUNCWEAK   DEFAULT   10 foo_alias
 9: 0640 7 FUNCGLOBAL DEFAULT   10 foo
$ readelf --dyn-sym -W foo.so |grep bar
 4: 002008cc 4 OBJECT  GLOBAL DEFAULT   21 bar
 6: 002008cc 4 OBJECT  WEAK   DEFAULT   21 bar_alias

this silently breaks the libc if it's compiled with lto

my gcc version is 6.0.0 20160113, tested on x86_64 and aarch64 targets.

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |5.3.0

[Bug c++/69273] New: internal compiler error: in assign_temp, at function.c:961

[sbergman at redhat dot com]

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

Bug ID: 69273
   Summary: internal compiler error: in assign_temp, at
function.c:961
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With current trunk sources:

> $ gcc/trunk/inst/bin/g++ -v
> Using built-in specs.
> COLLECT_GCC=gcc/trunk/inst/bin/g++
> COLLECT_LTO_WRAPPER=/home/sbergman/gcc/trunk/inst/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../src/trunk/configure 
> --prefix=/home/sbergman/gcc/trunk/inst --enable-languages=c,c++,lto
> Thread model: posix
> gcc version 6.0.0 20160114 (experimental) (GCC) 

> $ cat test.cc
> struct S0 { virtual void f0() = 0; };
> struct S1: S0 { void f0() { S0::f0(); } };
> struct T {
> T(S1 * p) { p->f0(); }
> T(T const &);
> };
> struct S2: S1 {
> virtual T f1(bool b);
> virtual T f2(bool b);
> };
> T S2::f1(bool b) {
> if (b) return this;
> return this;
> }
> T S2::f2(bool b) {
> if (b) return this;
> return this;
> }

> $ gcc/trunk/inst/bin/g++ -O2 -c test.cc
> test.cc: In member function ‘virtual T S2::f1(bool)’:
> test.cc:15:3: internal compiler error: in assign_temp, at function.c:961
>  T S2::f1(bool b) {
>^~
>
> 0xa4ad93 assign_temp(tree_node*, int, int)
>   ../../src/trunk/gcc/function.c:961
> 0x8d078e expand_call(tree_node*, rtx_def*, int)
>   ../../src/trunk/gcc/calls.c:2552
> 0x9e037c expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
> expand_modifier, rtx_def**, bool)
>   ../../src/trunk/gcc/expr.c:10585
> 0x8e164a expand_expr
>   ../../src/trunk/gcc/expr.h:256
> 0x8e164a expand_call_stmt
>   ../../src/trunk/gcc/cfgexpand.c:2648
> 0x8e164a expand_gimple_stmt_1
>   ../../src/trunk/gcc/cfgexpand.c:3536
> 0x8e164a expand_gimple_stmt
>   ../../src/trunk/gcc/cfgexpand.c:3702
> 0x8e3fc4 expand_gimple_basic_block
>   ../../src/trunk/gcc/cfgexpand.c:5708
> 0x8e8f96 execute
>   ../../src/trunk/gcc/cfgexpand.c:6323
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #3 from Nick Clifton  ---
The patch checked in fixes this PR.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/68955] [6 Regression] wrong code at -O3 on x86-64-linux-gnu in 32-bit mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/68936] [6 Regression] ICE: tree check: expected call_expr, have target_expr in build_min_non_dep_call_vec, at cp/tree.c:2744

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug lto/69003] [4.9/5/6 Regression] Undefined reference with gcc -r incremental linking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
   Priority|P3  |P2
 CC||hubicka at gcc dot gnu.org
  Known to work||4.8.3

--- Comment #3 from Richard Biener  ---
I've learned that partial linking isn't really supported with LTO.  Not sure
which part of the patches that try to implement it were applied for GCC 6 and
what is expected to work now.

[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2