[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #20 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Fri Nov 25 08:03:51 2016
New Revision: 242858

URL: https://gcc.gnu.org/viewcvs?rev=242858&root=gcc&view=rev
Log:
2016-11-25  Jakub Jelinek  
Prathamesh Kulkarni  

PR middle-end/78501
* tree-vrp.c (extract_range_basic): Check for ptrdiff_type_node to be
non null and it's precision matches precision of lhs's type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
The test needs

/* { dg-require-effective-target int128 } */

instead of

/* { dg-require-effective-target lp64 } */

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/78517] error: non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #2 from Richard Biener  ---
Probably a dup (fix approved).

[Bug ipa/78515] [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I'll have a look.

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||6.1.1
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Thus fixed.

[Bug c++/78514] ICE in tsubst, at cp/pt.c:13073

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
clang++ rejects it (version 3.6.1):

> clang++ -S t.C -std=c++11
t.C:21:39: error: extraneous template parameter list in alias template
  declaration
template  template  using n = g;
~ ^
t.C:23:34: error: template argument for template type parameter must be a type
template  void increasing(n) {
 ^
t.C:21:11: note: template parameter is declared here
template  template  using n = g;
  ^
t.C:24:16: error: implicit instantiation of undefined template
  'g'
increasing(o<10>{});
   ^
t.C:5:36: note: template is declared here
template  struct g;
   ^
3 errors generated.

[Bug c++/78514] ICE in tsubst, at cp/pt.c:13073

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail|5.3.1, 6.2.1|4.7.4, 4.8.5, 4.9.4, 5.4.0,
   ||6.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, all releases supporting (4.7.0+) -std=c++11 fail. Is it really a
valid code, looks clang rejects the snippet?

[Bug middle-end/78517] error: non-trivial conversion at assignment

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed.

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/78517] error: non-trivial conversion at assignment

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Yes, it duplicates PR78510.

[Bug middle-end/78510] [7 Regression] ICE on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from amker at gcc dot gnu.org ---
*** Bug 78517 has been marked as a duplicate of this bug. ***

[Bug middle-end/78517] error: non-trivial conversion at assignment

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from amker at gcc dot gnu.org ---
duplicated.

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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Of the testcases originally highlighted:

alloc_comp_assign_2.f90  still leaks
alloc_comp_assign_4.f90  still leaks
alloc_comp_basics_2.f90  still leaks
alloc_comp_basics_5.f90  is OK - probably always was!
alloc_comp_constructor_2.f90 still leaks
alloc_comp_initializer_1.f90 still leaks

alloc_comp_constructor_2.f90 also leaks

It's time to deal with this!

Paul

[Bug gcov-profile/78467] [7 regression] gcc.dg/tree-prof/comp-goto-1.c FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 25 08:51:38 2016
New Revision: 242864

URL: https://gcc.gnu.org/viewcvs?rev=242864&root=gcc&view=rev
Log:
PR gcov-profile/78467
* gcc.dg/tree-prof/comp-goto-1.c (insn_t): Change offset to
signed int.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c

[Bug gcov-profile/78467] [7 regression] gcc.dg/tree-prof/comp-goto-1.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Assuming this is fixed.  Please reopen if not.

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note -fcompare-debug compares the -fdump-final-insns= dumps, those include RTL,
but not the LTO streams.  So while it might not be very useful for -flto, there
is no inherent reason why it wouldn't work.
Of course more interesting is the comparison of -g/-g0 -fdump-final-insns= from
the final compilation(s) by lto1.

[Bug tree-optimization/78396] [7 regression] gcc.dg/vect/bb-slp-cond-1.c FAILs after fix for PR77848

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 25 08:59:28 2016
New Revision: 242865

URL: https://gcc.gnu.org/viewcvs?rev=242865&root=gcc&view=rev
Log:
2016-11-25  Richard Biener  

PR tree-optimization/78396
* tree-vectorizer.c (vectorize_loops): When the if-converted
body contains masked loads or stores do not attempt to
basic-block-vectorize it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Ah, I can reproduce even on current trunk with additional
-fno-printf-return-value.

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #9 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Fri Nov 25 09:25:31 2016
New Revision: 242866

URL: https://gcc.gnu.org/viewcvs?rev=242866&root=gcc&view=rev
Log:
[Patch i386] PR78509 - TARGET_C_EXCESS_PRECISION should not return
 "unpredictable" for EXCESS_PRECISION_TYPE_STANDARD

gcc/

PR target/78509
* config/i386/i386.c (i386_excess_precision): Do not return
FLT_EVAL_METHOD_UNPREDICTABLE when "type" is
EXCESS_PRECISION_TYPE_STANDARD.
* target.def (excess_precision): Document that targets should
not return FLT_EVAL_METHOD_UNPREDICTABLE when "type" is
EXCESS_PRECISION_TYPE_STANDARD or EXCESS_PRECISION_TYPE_FAST.
Fix typo in first sentence.
* doc/tm.texi: Regenerate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/tm.texi
trunk/gcc/target.def

[Bug ipa/78494] Issues pointed out by valgrind --tool=exp-dhat

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Another issue. cse only uses 1% of its allocations:

==15253==  17 of 100    
==15253== max-live:536,400 in 1 blocks  
==15253== tot-alloc:   223,905,600 in 11,785 blocks (avg size 18999.20) 
==15253== deaths:  11,785, at avg age 72,977 (0.00% of prog lifetime)   
==15253== acc-ratios:  0.01 rd, 0.01 wr  (2,440,706 b-read, 2,714,563
b-written)  
==15253==at 0x402CFAF: malloc (vg_replace_malloc.c:299) 
==15253==by 0x15F4CD7: xmalloc (xmalloc.c:148)  
==15253==by 0x1473D1B: cse_main(rtx_insn*, int) [clone .isra.69]
(cse.c:6514)
==15253==by 0x1474896: (anonymous namespace)::pass_cse::execute(function*)
(cse.c:7567)
==15253==by 0xCA0793: execute_one_pass(opt_pass*) (passes.c:2370)   
==15253==by 0xCA0EB0: execute_pass_list_1(opt_pass*) (passes.c:2459)
==15253==by 0xCA0EC2: execute_pass_list_1(opt_pass*) (passes.c:2460)
==15253==by 0xCA0F0C: execute_pass_list(function*, opt_pass*)
(passes.c:2470) 
==15253==by 0x96B0DD: cgraph_node::expand() (cgraphunit.c:2001) 
==15253==by 0x96C869: symbol_table::compile() [clone .part.47]
(cgraphunit.c:2137) 
==15253==by 0x96EF54: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2587) 
==15253==by 0xD75222: compile_file() (toplev.c:488)

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #10 from James Greenhalgh  ---
Should now be fixed, but I'll leave open for Rainer to confirm.

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Then GCC 7 won't build any kernel with KASAN until those kernel patches go in?
That's unfortunate, but I guess it's not easy to teach GCC to enable
-fsanitize-use-after-scope only if the runtime supports the new functions

[Bug tree-optimization/70965] [7 Regression] ICE on released SSA name during IPA SRA

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Fri Nov 25 09:49:19 2016
New Revision: 242867

URL: https://gcc.gnu.org/viewcvs?rev=242867&root=gcc&view=rev
Log:
[PR 70965] Schedule extra rebuild_cgraph_edges

2016-11-25  Martin Jambor  

PR tree-optimization/70965
* passes.def (pass_build_ssa_passes): Add pass_rebuild_cgraph_edges.

gcc/testsuite/
* g++.dg/pr70965.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/pr70965.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to ktkachov from comment #4)
> Then GCC 7 won't build any kernel with KASAN until those kernel patches go
> in?
> That's unfortunate, but I guess it's not easy to teach GCC to enable
> -fsanitize-use-after-scope only if the runtime supports the new functions

Unfortunately, yes. Problem is that kernel has its own runtime implementation
and it must be in sync.

The same problem is with GCOV runtime, where I also did some small
modifications and following patch would be needed:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1279372.html

[Bug ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Nov 25 09:59:45 2016
New Revision: 242868

URL: https://gcc.gnu.org/viewcvs?rev=242868&root=gcc&view=rev
Log:
PR ada/67205
* config/mips/mips.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Define.

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

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[dvyukov at google dot com]

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

--- Comment #6 from Dmitry Vyukov  ---
> Then GCC 7 won't build any kernel with KASAN until those kernel patches go in?

Yes.

Kernel passes -fsanitize=kernel-address, some behavior tuning can be done based
on that flag.

Please notify kasan-...@googlegroups.com of such changes ahead of time.

I discovered the breakage only because my 6.something started producing broken
kernel, so I updated gcc to head and hit these build failures.
There was another, more subtle one. Description of globals was extended with a
new field. Globals are passed in an array, as the result kernel iterated over
the array with a wrong step which corrupted memory. There is a pending kernel
patch for this as well:
https://groups.google.com/d/msg/kasan-dev/-KfrM62xGfM/XoQIjyjMAgAJ

[Bug tree-optimization/70965] [7 Regression] ICE on released SSA name during IPA SRA

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/77673] [5/6/7 Regression] 4-byte load generated instead of 1-byte load, possibly reading past the end of object

[thopre01 at gcc dot gnu.org]

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

--- Comment #8 from Thomas Preud'homme  ---
Author: thopre01
Date: Fri Nov 25 10:03:38 2016
New Revision: 242869

URL: https://gcc.gnu.org/viewcvs?rev=242869&root=gcc&view=rev
Log:
Fix PR77673: bswap loads passed end of object

2016-11-25  Thomas Preud'homme  

gcc/
PR tree-optimization/77673
* tree-ssa-math-opts.c (struct symbolic_number): Add new src field.
(init_symbolic_number): Initialize src field from src parameter.
(perform_symbolic_merge): Select most dominated statement as the
source statement.  Set src field of resulting n structure from the
input src with the lowest address.
(find_bswap_or_nop): Rename source_stmt into ins_stmt.
(bswap_replace): Rename src_stmt into ins_stmt.  Initially get source
of load from src field rather than insertion statement.  Cancel
optimization if statement analyzed is not dominated by the insertion
statement.
(pass_optimize_bswap::execute): Rename src_stmt to ins_stmt.  Compute
dominance information.

gcc/testsuite/
PR tree-optimization/77673
* gcc.dg/pr77673.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr77673.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #10 from amker at gcc dot gnu.org ---
Hi Prathamesh,
I saw it starting XPASS on arm-none-eabi in test now:

spawn /.../gcc/xgcc -B/.../gcc/ /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Wuninitialized -O2 -S -o
uninit-pred-8_a.s
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be used
uninitialized in this function [-Wmaybe-uninitialized]
output is:
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
/.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be used
uninitialized in this function [-Wmaybe-uninitialized]

XPASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
21)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 24)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 27)
PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)

The gcc is configured as:
/.../gcc/configure --target=arm-none-eabi --prefix=/.../install --with-gmp=...
--with-mpfr=... --with-mpc=... --with-isl=... --with-pkgversion=unknown
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++ --with-newlib

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
At a first glance with gfortran-6 (configured with --enable-checking=yes),
still ICEs for all posted and unposted cases. A dedicated one :


$ gfortran-6 z3.f90
f951: internal compiler error: Segmentation fault
0xbb372f crash_signal
../../gcc/toplev.c:333
0x61cf32 create_character_initializer
../../gcc/fortran/data.c:191
0x61cf32 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:488
0x693442 check_data_variable
../../gcc/fortran/resolve.c:14714
0x693442 traverse_data_var
../../gcc/fortran/resolve.c:14843
0x6937ad traverse_data_list
../../gcc/fortran/resolve.c:14799
0x6937ad traverse_data_var
../../gcc/fortran/resolve.c:14841
0x69dc71 resolve_data
../../gcc/fortran/resolve.c:14898
0x69dc71 resolve_types
../../gcc/fortran/resolve.c:15651
0x69947c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15737
0x6848da resolve_all_program_units
../../gcc/fortran/parse.c:5849
0x6848da gfc_parse_file()
../../gcc/fortran/parse.c:6101
0x6c7212 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:201


Please let me have a closer look next week.

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---

FYI, for some circumstances there existed related issues like :

using LANG=de_DE.UTF-8

f951: internal compiler error: Speicherzugriffsfehler
0xc4265f crash_signal
../../gcc/toplev.c:333
0x13f4b86 diagnostic_action_after_output(diagnostic_context*, diagnostic_t)
../../gcc/diagnostic.c:509
0x13f542a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:956
0x68dbff gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1327
0x6f1d93 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6549
...

[Bug c++/78523] New: ICE on valid lambda code with implicit capture

[rjpcal at gmail dot com]

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

Bug ID: 78523
   Summary: ICE on valid lambda code with implicit capture
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjpcal at gmail dot com
  Target Milestone: ---

Created attachment 40146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40146&action=edit
Short snippet (8 lines) yielding the ICE

$ cat test.cc
int bar();

void foo()
{
  const int t = bar();
  auto f = [=](auto x){ return t; };
  f(0);
}

$ g++ -std=gnu++14 -c test.cc
test.cc: In lambda function:
test.cc:6:35: internal compiler error: Segmentation fault
   auto f = [=](auto x){ return t; };
   ^

Results with different capture lists:

[=] -- ICE (shown above)
[&] -- also ICE
[t] -- works as expected (no ICE)


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 


I see Bug 49598 has a very similar-sounding summary and test case but that was
apparently found+fixed in 4.6/4.7, and this is occurring in 5.4.

[Bug tree-optimization/78343] [6/7 Regression] Loop is not eliminated

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 25 10:22:57 2016
New Revision: 242872

URL: https://gcc.gnu.org/viewcvs?rev=242872&root=gcc&view=rev
Log:
2016-11-24  Richard Biener  

PR tree-optimization/78343
* passes.def: Add CD-DCE pass after loop splitting.
* tree-ssa-dce.c (find_obviously_necessary_stmts): Move
SCEV init/finalize ...
(perform_tree_ssa_dce): ... here.  Deal with being
executed inside the loop pipeline in aggressive mode.

* gcc.dg/tree-ssa/sccp-2.c: New testcase.
* gcc.dg/autopar/uns-outer-6.c: Adjust.
* gcc.dg/tree-ssa/20030808-1.c: Likewise.
* gcc.dg/tree-ssa/20040305-1.c: Likewise.
* gcc.dg/vect/pr38529.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/sccp-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/autopar/uns-outer-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030808-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040305-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr38529.c
trunk/gcc/tree-ssa-dce.c

[Bug tree-optimization/78343] [6 Regression] Loop is not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] Loop is|[6 Regression] Loop is not
   |not eliminated  |eliminated
  Known to fail|7.0 |

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
(In reply to amker from comment #10)
> Hi Prathamesh,
> I saw it starting XPASS on arm-none-eabi in test now:
> 
> spawn /.../gcc/xgcc -B/.../gcc/
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c -fno-diagnostics-show-caret
> -fdiagnostics-color=never -Wuninitialized -O2 -S -o uninit-pred-8_a.s
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> output is:
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c: In function 'foo_2':
> /.../gcc/gcc/testsuite/gcc.dg/uninit-pred-8_a.c:43:7: warning: 'v' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> 
> XPASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 21)
> PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 24)
> PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
> 27)
> PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
> PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)
> 
> The gcc is configured as:
> /.../gcc/configure --target=arm-none-eabi --prefix=/.../install
> --with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=...
> --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads
> --disable-tls --enable-checking=yes --enable-languages=c,c++ --with-newlib

The test should ideally be XFAIL'd only for cortex-m7 subtarget of
arm-none-eabi.
However I am not sure if that's possible, so XFAIL'd for arm-none-eabi.
With cortex-m7 I am still seeing the XFAIL:

XFAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line
21)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 24)
PASS: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 27)
PASS: gcc.dg/uninit-pred-8_a.c warning (test for warnings, line 43)
PASS: gcc.dg/uninit-pred-8_a.c (test for excess errors)

Thanks,
Prathamesh

[Bug middle-end/78524] New: [7 regression] failure of ACATS c41104a at -O0

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 78524
   Summary: [7 regression] failure of ACATS c41104a at -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

It's a recently introduced ICE:

+===GNAT BUG DETECTED==+
| 7.0.0 20161125 (experimental) [trunk revision 242863] (x86_64-suse-linux) GCC
error:|
| in size_binop_loc, at fold-const.c:1744  |
| Error detected at c41104a.adb:60:33  |

so it probably comes from the recent match.pd changes.

[Bug middle-end/78524] [7 regression] failure of ACATS c41104a at -O0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  ---
Created attachment 40147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40147&action=edit
Reduced testcase

Compile with just gcc/gnat1 -quiet p.adb

[Bug gcov-profile/78467] [7 regression] gcc.dg/tree-prof/comp-goto-1.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Jakub Jelinek  ---
> Assuming this is fixed.  Please reopen if not.

It is: I'd included it in last night's bootstrap.  After Andreas' hint,
I just had to look three times until I realized that we have too
identically named tests in different directories ;-(

Rainer

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from James Greenhalgh  ---
> Should now be fixed, but I'll leave open for Rainer to confirm.

I'd included your patch in last night's i386-pc-solaris2.12 bootstraps
and the failures were gone indeed.  Thanks.

However, there's one new failure that might be related:

+FAIL: gcc.target/i386/pr42549.c execution test

32-bit x86 only.  The test aborts:

#0  0xfdd3e657 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfdd3779f in thr_kill () from /lib/libc.so.1
#2  0xfdc7975a in raise () from /lib/libc.so.1
#3  0xfdc4b37e in abort () from /lib/libc.so.1
#4  0x08050bd5 in mmx_3dnow_test ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr42549.c:37
#5  do_test ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h:12
#6  0x08050c31 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h:25

(gdb) p D[1].f[0]
$1 = -nan(0x40)
(gdb) p D[1].f[1]
$2 = 3

I don't see it in the gcc-testresults archive yet and it may well be a
coincidence: this wasn't an exact regtest, but top-of-tree one day later.

Rainer

[Bug go/78525] New: use -O2 for "go build" by default

[trippels at gcc dot gnu.org]

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

Bug ID: 78525
   Summary: use -O2 for "go build" by default
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: trippels at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

Currently "go build" builds binaries without any optimization.
This is in contrast to the official "go build" command, that optimizes by
default.

Wouldn't it make sense to add "-O2" (or even -O3) to the default gccgoflags?

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #12 from James Greenhalgh  ---
I tried looking at the generated assembly for that test with the compilers I
built before my patch series, and after the patch series + the fix above. I
couldn't see any difference in code generated for the testcase you mention for
each of the sets of options Jakub gave above (with -m3dnow, -O2, -m32 for the
testcase).

If this turns out to be my fault, I'll gladly look in to it - but I'll need
help getting the x86 flags right again!

[Bug rtl-optimization/78526] New: [7 Regression] ICE: in decompose, at rtl.h:2117 with -g -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 78526
   Summary: [7 Regression] ICE: in decompose, at rtl.h:2117 with
-g -mavx512bw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-ccp -fno-tree-sra -g -mavx512bw
testcase.c
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in decompose, at rtl.h:2117
 }
 ^
0xbbcb00 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2117
0xbbcb00 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:976
0xbbcb00 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:753
0xbbcb00 unsigned long wi::extract_uhwi
>(std::pair const&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:3054
0xbbcb00 simplify_immed_subreg
/repo/gcc-trunk/gcc/simplify-rtx.c:5745
0xbd62e8 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
/repo/gcc-trunk/gcc/simplify-rtx.c:6220
0xbd8666 simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/repo/gcc-trunk/gcc/simplify-rtx.c:491
0xec18dc propagate_for_debug(rtx_insn*, rtx_insn*, rtx_def*, rtx_def*,
basic_block_def*)
/repo/gcc-trunk/gcc/valtrack.c:201
0x14ac03c try_combine
/repo/gcc-trunk/gcc/combine.c:4357
0x14b3660 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1264
0x14b3660 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:14548
0x14b3660 execute
/repo/gcc-trunk/gcc/combine.c:14593
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242789-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242789-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161123 (experimental) (GCC) 


The reduced testcase has out-of-bounds vector index; the original testcase
didn't have it though.


Tested revisions:
r242789 - FAIL
r242600 - FAIL
6-branch r242830 - OK

[Bug c/78527] New: ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[chengniansun at gmail dot com]

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

Bug ID: 78527
   Summary: ice on valid C code at -O3 in both 32-bit and 64-bit
modes on x86_64-linux-gnu (internal compiler error: in
smallest_mode_for_size, at stor-layout.c:364)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161125 (experimental) [trunk revision 242857] (GCC) 
$ 
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:16:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:364
 }
 ^
0xbd6ff0 smallest_mode_for_size(unsigned int, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:364
0x12ad7b6 make_extraction
../../gcc-source-trunk/gcc/combine.c:7557
0x12b1998 make_compound_operation_int
../../gcc-source-trunk/gcc/combine.c:8102
0x12b1998 make_compound_operation(rtx_def*, rtx_code)
../../gcc-source-trunk/gcc/combine.c:8210
0x12b134a make_compound_operation(rtx_def*, rtx_code)
../../gcc-source-trunk/gcc/combine.c:8234
0x12b4139 simplify_set
../../gcc-source-trunk/gcc/combine.c:6730
0x12b57e7 combine_simplify_rtx
../../gcc-source-trunk/gcc/combine.c:6167
0x12b7a52 subst
../../gcc-source-trunk/gcc/combine.c:5467
0x12b752a subst
../../gcc-source-trunk/gcc/combine.c:5335
0x12b8e07 try_combine
../../gcc-source-trunk/gcc/combine.c:3313
0x12be812 combine_instructions
../../gcc-source-trunk/gcc/combine.c:1285
0x12be812 rest_of_handle_combine
../../gcc-source-trunk/gcc/combine.c:14549
0x12be812 execute
../../gcc-source-trunk/gcc/combine.c:14594
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.
$ 
$ cat small.c
unsigned a;
short b, e;
int *c;
char d;
int main() {
  int f = 80;
  for (;;) {
if (f > 432)
  *c = a;
while (b)
  if (d)
e = -(a >> f);
c = &f;
b = e;
  }
}
$

[Bug c++/78522] -O2 optimization confused by enum and pointer usage in constructors.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #2 from Jonathan Wakely  ---
(In reply to Samuel T C Huang from comment #0)
> helper.run(reinterpret_cast(&value_type));

The problem is here. This cast leads to an aliasing violation when you assign
through the pointer, so the program has undefined behaviour.

Don't do that.

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
This seems to be IPA-ICF bug.
With -fdump-ipa-icf-all
I'm seeing differences like:
   group: with 1 classes:
-class with id: 1, hash: 3010449829, items: 2
- 
_ZNK8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE(0x7fdb1be7b900/2)
_ZN8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE(0x7fdb1be7b800/1)
 
+class with id: 0, hash: 1515816170, items: 2
+  _ZN11VwViewer_2D15undrawStickyBoxEv(0x7f12887d2c00/4)
_ZN11VwViewer_2D13drawStickyBoxEv(0x7f12887d2b00/3) 
   group: with 1 classes:
-class with id: 0, hash: 698082993, items: 2
-  _ZN11VwViewer_2D15undrawStickyBoxEv(0x7fdb1be7bb00/4)
_ZN11VwViewer_2D13drawStickyBoxEv(0x7fdb1be7ba00/3) 
+class with id: 1, hash: 3232079217, items: 2
+ 
_ZNK8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE(0x7f12887d2a00/2)
_ZN8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE(0x7f12887d2900/1)
 
 Dump after WPA based types groups
 Congruence classes: 2 (unique hash values: 2), with total: 4 items
 Class size histogram [num of members]: number of classe number of classess

Remember the basic rules for -fcompare-debug - DECL_UID can be different, but
their order must be the same (essentially -g can create bigger gaps in between
them), SSA_NAME_VERSION must be identical, and cfun->funcdef_no must be
identical.
The last one is what breaks, IPA-ICF creates funcdef_no that are swapped.
Hashing to different hash values is fine, but care must be taken when actually
traversing the hash tables to generate stuff in the same order between -g and
-g0 if it could affect code generation in any way.

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 40149
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40149&action=edit
gcc7-pr78211.patch

Untested fix.

[Bug rtl-optimization/78526] [7 Regression] ICE: in decompose, at rtl.h:2117 with -g -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug rtl-optimization/78527] [7 Regression] ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
  Component|c   |rtl-optimization
   Target Milestone|--- |7.0
Summary|ice on valid C code at -O3  |[7 Regression] ice on valid
   |in both 32-bit and 64-bit   |C code at -O3 in both
   |modes on x86_64-linux-gnu   |32-bit and 64-bit modes on
   |(internal compiler error:   |x86_64-linux-gnu (internal
   |in smallest_mode_for_size,  |compiler error: in
   |at stor-layout.c:364)   |smallest_mode_for_size, at
   ||stor-layout.c:364)
 Ever confirmed|0   |1

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

[Bug middle-end/78524] [7 regression] failure of ACATS c41104a at -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||amker at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug c++/78523] ICE on valid lambda code with implicit capture

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
  Known to work||6.2.1, 7.0
 Ever confirmed|0   |1
  Known to fail||5.4.1

--- Comment #1 from Richard Biener  ---
Confirmed, works on the GCC 6 branch and trunk.

[Bug c++/78523] [5 Regression] ICE on valid lambda code with implicit capture

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.4
   Target Milestone|--- |5.5
Summary|ICE on valid lambda code|[5 Regression] ICE on valid
   |with implicit capture   |lambda code with implicit
   ||capture

--- Comment #2 from Richard Biener  ---
Works on the GCC 4.9 branch.

[Bug middle-end/78517] error: non-trivial conversion at assignment

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Nov 25 11:45:43 2016
New Revision: 242874

URL: https://gcc.gnu.org/viewcvs?rev=242874&root=gcc&view=rev
Log:
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* match.pd ((cond (cmp (convert1? @1) @3) (convert2? @1) @2)): Use
cmp directly, rather than cmp_code.  Initialize code to ERROR_MARK
and set it to result code if transformation is valid.  Use code EQ
directly in last simplification case.

gcc/testsuite
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* g++.dg/torture/pr78507.C: New test.
* gcc.dg/torture/pr78510.c: New test.
* gcc.dg/torture/pr78517.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78507.C
trunk/gcc/testsuite/gcc.dg/torture/pr78510.c
trunk/gcc/testsuite/gcc.dg/torture/pr78517.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78510] [7 Regression] ICE on valid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Nov 25 11:45:43 2016
New Revision: 242874

URL: https://gcc.gnu.org/viewcvs?rev=242874&root=gcc&view=rev
Log:
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* match.pd ((cond (cmp (convert1? @1) @3) (convert2? @1) @2)): Use
cmp directly, rather than cmp_code.  Initialize code to ERROR_MARK
and set it to result code if transformation is valid.  Use code EQ
directly in last simplification case.

gcc/testsuite
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* g++.dg/torture/pr78507.C: New test.
* gcc.dg/torture/pr78510.c: New test.
* gcc.dg/torture/pr78517.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78507.C
trunk/gcc/testsuite/gcc.dg/torture/pr78510.c
trunk/gcc/testsuite/gcc.dg/torture/pr78517.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Nov 25 11:45:43 2016
New Revision: 242874

URL: https://gcc.gnu.org/viewcvs?rev=242874&root=gcc&view=rev
Log:
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* match.pd ((cond (cmp (convert1? @1) @3) (convert2? @1) @2)): Use
cmp directly, rather than cmp_code.  Initialize code to ERROR_MARK
and set it to result code if transformation is valid.  Use code EQ
directly in last simplification case.

gcc/testsuite
PR middle-end/78507
PR middle-end/78510
PR middle-end/78517
* g++.dg/torture/pr78507.C: New test.
* gcc.dg/torture/pr78510.c: New test.
* gcc.dg/torture/pr78517.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78507.C
trunk/gcc/testsuite/gcc.dg/torture/pr78510.c
trunk/gcc/testsuite/gcc.dg/torture/pr78517.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This is tsubst ICE on ADDR_EXPR .

[Bug middle-end/78524] [7 regression] failure of ACATS c41104a at -O0

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Hi Eric,
Could you help verify if below commit fix this please?

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242874

Thanks.

[Bug fortran/78518] [6/7 Regression] Warning format regression

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||janus at gcc dot gnu.org
Summary|Warning format regression   |[6/7 Regression] Warning
   ||format regression
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to physiker from comment #0)
> gfortran-7 -W -Wall t.f90
> t.f90:3:14:
> 
>call s(a, b)
>   1
> Warning: Type mismatch in argument »a« at (1); passed REAL(4) to REAL(8)
> [-Wargument-mismatch]

I can confirm this behavior with trunk and 6.2.0 20161005 (Ubuntu
6.2.0-5ubuntu12).


> gfortran-fsf-6  -W -Wall t.f90
> t.f90:3:9:
> 
>call s(a, b)
>  1
> Warning: Type mismatch in argument »a« at (1); passed REAL(4) to REAL(8)

This is what I get with 5.4.1 20160929 (Ubuntu 5.4.1-2ubuntu2). Which version
of gfortran 6 are you using exactly?

Note that even earlier versions (4.x) put the '1' right under the 'a', not
under the opening brace.

The warning comes from compare_parameter in interface.c.

[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This seems to be infinite recursion in subst/combine_simplify_rtx on
expression:
(plus:SI (ltu:SI (plus:SI (if_then_else:SI (eq (reg:CC 180)
(const_int 0 [0]))
(reg:SI 155 [ _1+-3 ])
(reg:SI 175 [ vu+4 ]))
(reg:SI 155 [ _1+-3 ]))
(if_then_else:SI (eq (reg:CC 180)
(const_int 0 [0]))
(reg:SI 155 [ _1+-3 ])
(reg:SI 175 [ vu+4 ])))
(reg:SI 174 [ vu ]))
The subst is from (pc) to (pc), i.e. simplification.

[Bug middle-end/78524] [7 regression] failure of ACATS c41104a at -O0

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Isn't fixed by that commit.

[Bug c++/72808] [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 40150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40150&action=edit
gcc7-pr72808.patch

Untested fix.  Alternatively we could just update TYPE_FIELDS of the variant
types.

[Bug middle-end/78524] [7 regression] failure of ACATS c41104a at -O0

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The MIN_EXPR it builds is correct now though.  Looks like a bug in Adas
max_size to me when invoked on

 
unit size 
align 8 symtab 0 alias set 4 canonical type 0x761e7498
precision 8 min  max  context  RM min
 RM max  debug
type 
pointer_to_this >
public unsigned string-flag QI size  unit
size 
align 8 symtab 0 alias set 4 canonical type 0x75e80dc8 precision 8
min  max  context
 RM size  RM min
 RM max 
chain >

arg 0 
visited
arg 0 
visited>
arg 1 
visited nonaddressable decl_4 VOID file p.adb line 7 col 13
align 8 offset_align 1 context 
initial >>
arg 1  constant 88>>

we end up with mismatched type lhs/rhs.  The placeholder is transformed to

(gdb) p debug_tree (lhs)
 
constant 87>

a signed integer constant.

[Bug ada/78524] [7 regression] failure of ACATS c41104a at -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |ada

--- Comment #6 from Richard Biener  ---
case tcc_reference:
  /* If this contains a PLACEHOLDER_EXPR, it is the thing we want to
 modify.  Otherwise, we treat it like a variable.  */
  if (CONTAINS_PLACEHOLDER_P (exp))
{
  tree val_type = TREE_TYPE (TREE_OPERAND (exp, 1));
  tree val = (max_p ? TYPE_MAX_VALUE (type) : TYPE_MIN_VALUE (type));
  return max_size (convert (get_base_type (val_type), val), true);
}

possibly misses a convert (type, ...) around the return value.  At least that
fixes it for me.

[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Fri Nov 25 12:23:43 2016
New Revision: 242875

URL: https://gcc.gnu.org/viewcvs?rev=242875&root=gcc&view=rev
Log:
2016-11-25  Andre Vehreschild  
Paul Thomas  

PR fortran/78293
* trans-expr.c (gfc_conv_procedure_call): Prepend deallocation
of alloctable components to post, rather than adding to
se->post.
* trans-stmt.c (gfc_trans_allocate): Move deallocation of expr3
allocatable components so that all expr3s are visited.

2016-11-25  Paul Thomas  

PR fortran/78293
* gfortran.dg/allocatable_function_10.f90: New test.
* gfortran.dg/class_array_15.f03: Increase builtin_free count
from 11 to 12.


Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_function_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 Ever confirmed|0   |1

--- Comment #15 from Eric Botcazou  ---
> Is the dynamic variable stack area properly aligned?  Since sparc.h does not
> define STACK_DYNAMIC_OFFSET it should be aligned to STACK_BONDARY, i.e. 64
> bits.

STACK_POINTER_OFFSET is 92 so the default value of STACK_DYNAMIC_OFFSET given
in function.c is certainly not aligned on STACK_BOUNDARY.

[Bug ada/78524] [7 regression] failure of ACATS c41104a at -O0

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> The MIN_EXPR it builds is correct now though.  Looks like a bug in Adas
> max_size to me when invoked on
> 
>   type  type  visited string-flag QI
> size 
> unit size 
> align 8 symtab 0 alias set 4 canonical type 0x761e7498
> precision 8 min  max  0x761e2d20 127> context  RM
> min  RM max 
> debug type 
> pointer_to_this >
> public unsigned string-flag QI size 
> unit size 
> align 8 symtab 0 alias set 4 canonical type 0x75e80dc8 precision
> 8 min  max 
> context  RM size  7> RM min  RM max  90>
> chain >
>
> arg 0  p__char___XDLU_87__90>
> visited
> arg 0  0x75ea4bd0 p__rec>
> visited>
> arg 1  p__char___XDLU_87__90>
> visited nonaddressable decl_4 VOID file p.adb line 7 col 13
> align 8 offset_align 1 context  p__rec> initial >>
> arg 1  p__char___XDLU_87__90> constant 88>>
> 
> we end up with mismatched type lhs/rhs.  The placeholder is transformed to
> 
> (gdb) p debug_tree (lhs)
>  
> constant 87>
> 
> a signed integer constant.

Thanks very much for helping.  I am trying to enable ada on my system.

Thanks.

[Bug ada/78524] [7 regression] failure of ACATS c41104a at -O0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
> we end up with mismatched type lhs/rhs.  The placeholder is transformed to
> 
> (gdb) p debug_tree (lhs)
>  
> constant 87>
> 
> a signed integer constant.

OK, I'll have a closer look.

[Bug fortran/61767] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Here is a slightly less verbose version of the test case which runs into the
same ICE:


module Communicator_Form
  implicit none
  type :: CommunicatorForm
  contains
final :: Finalize
  end type
  type :: MessageTemplate
type ( CommunicatorForm ), pointer :: Communicator
  end type
contains
  subroutine Finalize ( C )
type ( CommunicatorForm ) :: C
  end subroutine
end module

program p
  use Communicator_Form
  implicit none
  class ( MessageTemplate ), pointer :: M
end


The ICE is due to this assert ...

  gcc_assert (ancestor_wrapper && ancestor_wrapper->ref == NULL
  && ancestor_wrapper->expr_type == EXPR_VARIABLE);

... where ancestor_wrapper is NULL.

[Bug rtl-optimization/78527] [7 Regression] ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

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

[Bug rtl-optimization/78527] [7 Regression] ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
8097int width = GET_MODE_PRECISION (GET_MODE (inner))
8098- INTVAL (XEXP (inner, 1));
8099if (width > mode_width)
8100  width = mode_width;
8101new_rtx = make_extraction (mode, new_rtx, 0, XEXP (inner,
1),
8102   width, 1, 0, in_code ==
COMPARE);

x is
(subreg:HI (lshiftrt:SI (mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32])
(const_int 80 [0x50])) 0)
mode_width is 16, but width is -48.
I'd just guard it for valid shift counts.

[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Can it possibly be a duplicate of PR71724?

[Bug rtl-optimization/78527] [7 Regression] ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 40151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40151&action=edit
gcc7-pr78527.patch

Untested fix.

[Bug rtl-optimization/78526] [7 Regression] ICE: in decompose, at rtl.h:2117 with -g -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[vogt at linux dot vnet.ibm.com]

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

--- Comment #16 from Dominik Vogt  ---
In emit-rtl.c:init_emit(), the alignment of the virtual_stack_dynamic pointer
is hard coded to STACK_BOUNDARY:

  REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY; 

The backend must make sure that this promise is kept.  If that's what's
happening the Sparc backend then needs a fix similar to this Aix patch:

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01036.html
(r242589)

The idea (on AIX) is to round up the allocation size of the parameters area if
the function does dynamic allocation (calls_alloca is true).  This logic had to
be replicated in some macros in aix.h.  A solution for sparc probably looks
similar.

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
> In emit-rtl.c:init_emit(), the alignment of the virtual_stack_dynamic
> pointer is hard coded to STACK_BOUNDARY:
> 
>   REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY; 
> 
> The backend must make sure that this promise is kept.

If it defines STACK_DYNAMIC_OFFSET, sure, but if it doesn't, then IMO it's up
to the middle-end to be consistent with itself and do the alignment as before.

[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed, thanks.

[Bug ipa/78515] [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/78515] [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 25 14:05:04 2016
New Revision: 242876

URL: https://gcc.gnu.org/viewcvs?rev=242876&root=gcc&view=rev
Log:
2016-11-25  Richard Biener  

PR ipa/78515
* ipa-prop.c (compute_complex_assign_jump_func): Properly identify
unary, binary and single RHSs.
* tree.def (BIT_INSERT_EXPR): Adjust tree code name.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr78515.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.def

[Bug rtl-optimization/78526] [7 Regression] ICE: in decompose, at rtl.h:2117 with -g -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
What happens is that valtrack creates a paradoxical subreg:
(debug_insn 28 14 15 2 (var_location:V4TI D#2 (subreg:V4TI (reg:TI 94) 0)) -1
 (nil))
(insn 15 28 16 2 (set (subreg:TI (reg/v:V4TI 90 [ v ]) 0)
(reg:TI 94)) "pr78526.c":8 80 {*movti_internal}
 (expr_list:REG_DEAD (reg:TI 94)
(nil)))
during cse1 - with the meaning that nothing is known about the other elements
of the vector v, only about the first element.
But then simplify-rtx.c has bogus handling of CONST_WIDE_INT.
Though I'd say at least for debug info purposes we should be careful about
paradoxical subregs, because they mean the upper bits are not really defined
rather than zero or the value sign or zero extended.

[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Fri Nov 25 14:23:25 2016
New Revision: 242877

URL: https://gcc.gnu.org/viewcvs?rev=242877&root=gcc&view=rev
Log:
Don't use priority {cd}tors if not supported by a target (PR

PR gcov-profile/78086
* g++.dg/gcov/pr16855.C: Clean up the test case.
* g++.dg/gcov/pr16855-priority.C: New test.
* coverage.c (build_init_ctor): Don't use priority {cd}tors if
not supported by a target.  Set priority to 100 if possible.
(build_gcov_exit_decl): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/gcov/pr16855-priority.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/gcov/pr16855.C

[Bug web/71666] profile-generate not documented

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri Nov 25 14:23:54 2016
New Revision: 242878

URL: https://gcc.gnu.org/viewcvs?rev=242878&root=gcc&view=rev
Log:
Fix documentation reference (PR web/71666)

PR web/71666
* doc/invoke.texi (-fprofile-use): Fix reference to a section
where -fprofile-generate is documented.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed.

[Bug web/71666] profile-generate not documented

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug rtl-optimization/78526] [7 Regression] ICE: in decompose, at rtl.h:2117 with -g -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 40152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40152&action=edit
gcc7-pr78526.patch

Untested fix.

[Bug sanitizer/69840] two ASAN help nits

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Well, the change was rejected by LLVM folks and I think it doesn't worth
spending more time with that.

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[vogt at linux dot vnet.ibm.com]

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

--- Comment #18 from Dominik Vogt  ---
Another approach may be to make the middleend ask the backend for the actual
value of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM).  Since on Sparc
the address is always 4 mod 8, we'd get an additional gap for *each* alloca()
if the size is still required to be a multiple of STACK_BOUNDARY.

To prevent this it would also be necessary to adapt the logic in
explow.c:get_dynamic_stack_size().  Since a recent patch this function also
uses REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) as the alignment of the
beginning of that block, but still rounds the size up to a multiple of
STACK_BOUNDARY (explow.c:round_push()):

-- get_dynamic_stack_size() --
  /* Round the size to a multiple of the required stack alignment. 
 Since the stack is presumed to be rounded before this allocation, 
 this will maintain the required alignment. 

 If the stack grows downward, we could save an insn by subtracting 
 SIZE from the stack pointer and then aligning the stack pointer. 
 The problem with this is that the stack pointer may be unaligned 
 between the execution of the subtraction and alignment insns and 
 some machines do not allow this.  Even on those that do, some 
 signal handlers malfunction if a signal should occur between those 
 insns.  Since this is an extremely rare event, we have no reliable 
 way of knowing which systems have this problem.  So we avoid even 
 momentarily mis-aligning the stack.  */ 
  if (size_align % MAX_SUPPORTED_STACK_ALIGNMENT != 0) 
{ 
  size = round_push (size); 
-- END --

-- round_push() --
/* Round the size of a block to be pushed up to the boundary required 
   by this machine.  SIZE is the desired size, which need not be constant.  */ 

static rtx 
round_push (rtx size) 
{ 
  rtx align_rtx, alignm1_rtx; 

  if (!SUPPORTS_STACK_ALIGNMENT 
  || crtl->preferred_stack_boundary == MAX_SUPPORTED_STACK_ALIGNMENT) 
{ 
  int align = crtl->preferred_stack_boundary / BITS_PER_UNIT; 

  if (align == 1) 
return size; 

  if (CONST_INT_P (size)) 
...

  align_rtx = GEN_INT (align); 
  alignm1_rtx = GEN_INT (align - 1); 

-- END --

It looks quite tricky to change this code to deal with preferred_stack_boundary
and REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) at the same time.  What
if REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) is maller than
STACK_BOUNDARY and preferred_stack_boundary is larger than STACK_BOUNDARY?

In the end, both approaches result in the same amount of memory being
allocated.

[Bug gcov-profile/17040] GCOV not working properly on Windows platforms

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Guess it's resolved as gcov.c uses IS_DIR_SEPARATOR.

[Bug gcov-profile/28564] gcov fails to store the absolute path to the source files

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||hubicka at ucw dot cz,
   ||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
The request sound eligible for me.
What others think about it?

[Bug gcov-profile/35038] GCOV - using "--coverage" results in libgcov.a(_gcov.o) is referenced by DSO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-25
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
This is very old issue, can you please verify that it still exists?

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com

[Bug tree-optimization/78528] New: Recursion not optimized in simple case

[mawww at kakoune dot org]

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

Bug ID: 78528
   Summary: Recursion not optimized in simple case
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mawww at kakoune dot org
  Target Milestone: ---

The following code:

struct Int 
{ 
constexpr Int(int value) : m_value(value) {} 

constexpr friend Int operator+(Int lhs, Int rhs) { return {lhs.m_value +
rhs.m_value}; } 

int m_value; 
}; 

Int strlen(const char* s) 
{ 
return *s == 0 ? 0 : strlen(s+1) + 1; 
} 


when compiled with `-std=c++11 -O3` generates the following assembly for the
strlen function:

_Z6strlenPKc: 
.LFB4: 
.cfi_startproc 
cmpb$0, (%rdi) 
jne .L2 
xorl%eax, %eax 
ret 
.p2align 4,,10 
.p2align 3 
.L2: 
cmpb$0, 1(%rdi) 
movl$1, %eax 
jne .L12 
.L10: 
ret 
.p2align 4,,10 
.p2align 3 
.L12: 
cmpb$0, 2(%rdi) 
movl$2, %eax 
je  .L10 
subq$8, %rsp 
.cfi_def_cfa_offset 16 
addq$3, %rdi 
call_Z6strlenPKc 
addq$8, %rsp 
.cfi_def_cfa_offset 8 
addl$3, %eax 
ret 
.cfi_endproc 

As we can see, the generated code is still recursive, I think the optimizer
should have optimized that, is it correctly does when we use 'int' instead of
'Int'.

[Bug lto/78529] New: gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[amker at gcc dot gnu.org]

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

Bug ID: 78529
   Summary: gcc.c-torture/execute/builtins/strcat-chk.c failed
with lto/O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi,
With below commit:
commit c618308c1b2a474bd56ede831f681a49f4327d4c
Author: prathamesh3492 
Date:   Wed Nov 23 10:52:25 2016 +

2016-11-23  Richard Biener  
Prathamesh Kulkarni  

PR tree-optimization/78154
* tree-vrp.c (gimple_stmt_nonzero_warnv_p): Return true if function
returns it's argument and the argument is nonnull.
* builtin-attrs.def: Define ATTR_RETURNS_NONNULL,
ATT_RETNONNULL_NOTHROW_LEAF.
* builtins.def (BUILT_IN_MEMPCPY): Change attribute to
ATTR_RETNONNULL_NOTHROW_LEAF.
(BUILT_IN_STPCPY): Likewise.
(BUILT_IN_STPNCPY): Likewise.
(BUILT_IN_MEMPCPY_CHK): Likewise.
(BUILT_IN_STPCPY_CHK): Likewise.
(BUILT_IN_STPNCPY_CHK): Likewise.
(BUILT_IN_STRCAT): Change attribute to ATTR_RET1_NOTHROW_NONNULL_LEAF.
(BUILT_IN_STRNCAT): Likewise.
(BUILT_IN_STRNCPY): Likewise.
(BUILT_IN_MEMSET_CHK): Likewise.
(BUILT_IN_STRCAT_CHK): Likewise.
(BUILT_IN_STRCPY_CHK): Likewise.
(BUILT_IN_STRNCAT_CHK): Likewise.
(BUILT_IN_STRNCPY_CHK): Likewise.

testsuite/
* gcc.dg/tree-ssa/pr78154.c: New test.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242745
138bc75d-0d04-0410-961f-82ee72b054a4

We have new failure:
FAIL: gcc.c-torture/execute/builtins/strcat-chk.c execution, -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 

With/without the revision, there is difference in assembly like:
*** 1368,1387 
4023e4: b9401261ldr w1, [x19, #16]
4023e8: 6b3fcmp w1, w0
4023ec: 5401b.ne4023cc   // b.any
!   4023f0: 91001664add x4, x19, #0x5
!   4023f4: d2800802mov x2, #0x40   // #64
!   4023f8: 52800b01mov w1, #0x58   // #88
4023fc: aa1303e0mov x0, x19
402400: 94000950bl  404940 
402404: b9400a96ldr w22, [x20, #8]
402408: f9400297ldr x23, [x20]
40240c: d2800762mov x2, #0x3b   // #59
402410: 10071c81adr x1, 4107a0 
!   402414: aa0403e0mov x0, x4
402418: f90023b7str x23, [x29, #64]
40241c: b9004bb6str w22, [x29, #72]
402420: 97fffc0cbl  401450 <__strcat_chk>
!   402424: eb1fcmp x0, x0
402428: 54fffd21b.ne4023cc   // b.any
40242c: 10071820adr x0, 410730 
402430: f94023a2ldr x2, [x29, #64]
--- 1368,1387 
4023e4: b9401261ldr w1, [x19, #16]
4023e8: 6b3fcmp w1, w0
4023ec: 5401b.ne4023cc   // b.any
!   4023f0: d2800802mov x2, #0x40   // #64
!   4023f4: 52800b01mov w1, #0x58   // #88
!   4023f8: 91001678add x24, x19, #0x5
4023fc: aa1303e0mov x0, x19
402400: 94000950bl  404940 
402404: b9400a96ldr w22, [x20, #8]
402408: f9400297ldr x23, [x20]
40240c: d2800762mov x2, #0x3b   // #59
402410: 10071c81adr x1, 4107a0 
!   402414: aa1803e0mov x0, x24
402418: f90023b7str x23, [x29, #64]
40241c: b9004bb6str w22, [x29, #72]
402420: 97fffc0cbl  401450 <__strcat_chk>
!   402424: eb00031fcmp x24, x0
402428: 54fffd21b.ne4023cc   // b.any
40242c: 10071820adr x0, 410730 
402430: f94023a2ldr x2, [x29, #64]


Looks like the "cmp x0, x0" instruction is wrongly optimized?

GCC is configured as:

configure --target=aarch64-none-elf --prefix=... --with-gmp=... --with-mpfr=...
--with-mpc=... --with-isl=... --with-pkgversion=unknown --disable-shared
--disable-nls --disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++,fortran --with-newlib

[Bug libstdc++/78530] New: std::copy of volatile array triggers invalid conversion error

[poganoe at mail dot ru]

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

Bug ID: 78530
   Summary: std::copy of volatile array triggers invalid
conversion error
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: poganoe at mail dot ru
  Target Milestone: ---

I'm using arm-none-eabi-g++.exe (GNU Tools for ARM Embedded Processors) 5.4.1
20160919 (release) [ARM/embedded-5-branch revision 240496] for Windows. As far
as I know it's the latest version of arm-none-eabi target.

I'm trying to compile this:

#include 

volatile uint8_t buf[10];
volatile uint8_t dest[10];

int main(void)
{
std::copy(buf, buf+5, dest);
return 0;
}

And I get:

arm-none-eabi\include\c++\5.4.1\bits\stl_algobase.h:384:23: error: invalid
conversion from 'volatile void*' to 'void*' [-fpermissive]
  __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
   ^
: note:   initializing argument 1 of 'void* __builtin_memmove(void*,
const void*, unsigned int)'
arm-none-eabi\include\c++\5.4.1\bits\stl_algobase.h:384:23: error: invalid
conversion from 'const volatile void*' to 'const void*' [-fpermissive]
: note:   initializing argument 2 of 'void* __builtin_memmove(void*,
const void*, unsigned int)'

I'm not sure if it's correct behaviour but it certainly doesn't seem like it.
It should be possible to copy one array to the other array of the same type.

[Bug fortran/61767] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
The most immediate way to fix it is this:


Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 242875)
+++ gcc/fortran/class.c (working copy)
@@ -1569,10 +1569,10 @@ generate_finalization_wrapper (gfc_symbol *derived

   /* If there is no new finalizer and no new allocatable, return with
  an expr to the ancestor's one.  */
-  if (!expr_null_wrapper && !finalizable_comp
+  if (ancestor_wrapper && !expr_null_wrapper && !finalizable_comp
   && (!derived->f2k_derived || !derived->f2k_derived->finalizers))
 {
-  gcc_assert (ancestor_wrapper && ancestor_wrapper->ref == NULL
+  gcc_assert (ancestor_wrapper->ref == NULL
  && ancestor_wrapper->expr_type == EXPR_VARIABLE);
   vtab_final->initializer = gfc_copy_expr (ancestor_wrapper);
   vtab_final->ts.interface = vtab_final->initializer->symtree->n.sym;


This gets rid of the ICE on the given test case. I will check if it survives a
full regtest.

However one can wonder why we run into generate_finalization_wrapper for the
type MessageTemplate at all (which is not finalizable). It seems we do that for
all types that are used polymorphically, but I'm not sure it is really
necessary. Have to think about this some more.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[damian at sourceryinstitute dot org]

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

--- Comment #1 from Damian Rouson  ---
Section 9.7.1.2, paragraph 4, of the draft Fortran 2015 standard [1]:

"When an ALLOCATE statement is executed for which an allocate-object is a
coarray, there is an implicit synchronization of all active images in the
current team. On those images, if no error condition other than
STAT_STOPPED_IMAGE or STAT_FAILED_IMAGE occurs, execution of the segment
(11.6.2) following the statement is delayed until all other active images in
the current team have executed the same statement the same number of times in
this team. The coarray shall not become allocated on an image unless it is
successfully allocated on all active images in this team."

The important point is that no image can execute the segment following the
ALLOCATE statement until every image has executed the ALLOCATE statement the
same number of times (once in the example submitted in PR 78505). Because the
"SOURCE=" is part of the ALLOCATE statement, the action indicated by the
"SOURCE=" must complete on every image before any image can execute code that
comes after the corresponding ALLOCATE.

[1] http://open-std.org/JTC1/SC22/WG5/5559

[Bug fortran/61767] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> The most immediate way to fix it is this:
> [...]
> This gets rid of the ICE on the given test case. I will check if it survives
> a full regtest.

Indeed the patch in comment #5 does not seem to introduce any regressions in
the testsuite.

[Bug rtl-optimization/78527] [7 Regression] ice on valid C code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in smallest_mode_for_size, at stor-layout.c:364)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 25 17:12:29 2016
New Revision: 242879

URL: https://gcc.gnu.org/viewcvs?rev=242879&root=gcc&view=rev
Log:
PR rtl-optimization/78527
* combine.c (make_compound_operation_int): Ignore LSHIFTRT with
out of bounds shift count.

* gcc.c-torture/compile/pr78527.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr78527.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60853] [OOP] Failure to disambiguate generic with unlimited polymorphic

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Nov 25 17:22:37 2016
New Revision: 242880

URL: https://gcc.gnu.org/viewcvs?rev=242880&root=gcc&view=rev
Log:
2016-11-25  Janus Weil  

PR fortran/60853
* interface.c (gfc_compare_interfaces): Remove bad special case for
unlimited polymorphism. Refactor for loop.

2016-11-25  Janus Weil  

PR fortran/60853
* gfortran.dg/typebound_assignment_8.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60853] [OOP] Failure to disambiguate generic with unlimited polymorphic

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on GCC 7 trunk with r242880. Closing.

Thanks for the report!

[Bug bootstrap/78531] New: [7 Regression] gnat bootstrap broken on linux targets with _FORTIFY_SOURCE enabled

[doko at gcc dot gnu.org]

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

Bug ID: 78531
   Summary: [7 Regression] gnat bootstrap broken on linux targets
with _FORTIFY_SOURCE enabled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk r242874 on all linux architectures, and this patch to enable
the build with -D_FORTIFY_SOURCE=2. This works on the gcc-6-branch, system
glibc is 2.24.

--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -1176,6 +1176,10 @@ c_cpp_builtins (cpp_reader *pfile)
   builtin_define_with_value ("__REGISTER_PREFIX__", REGISTER_PREFIX, 0);
   builtin_define_with_value ("__USER_LABEL_PREFIX__", user_label_prefix, 0);

+  /* Fortify Source enabled by default for optimization levels > 0 */
+  if (optimize)
+builtin_define_with_int_value ("_FORTIFY_SOURCE", 2);
+
   /* Misc.  */
   if (flag_gnu89_inline)
 cpp_define (pfile, "__GNUC_GNU_INLINE__");


/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/bin/
-B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem
/usr/x86_64-linux-gnu/sys-include -isystem /<>/build/sys-include  
 -c -g -O2 -fno-stack-protector  -gnatpg  -W -Wall -nostdinc -I- -I.
-Iada/generated -Iada -I../../src/gcc/ada -I../../src/gcc/ada/gcc-interface
../../src/gcc/ada/a-charac.ads -o ada/a-charac.o
*** buffer overflow detected ***: /<>/build/./prev-gcc/gnat1
terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x790cb)[0x7f4945f4a0cb]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x54)[0x7f4945feb2c4]
/lib/x86_64-linux-gnu/libc.so.6(+0x118240)[0x7f4945fe9240]
/<>/build/./prev-gcc/gnat1[0x6f73c6]
/<>/build/./prev-gcc/gnat1(gigi+0xcc9)[0x705dc9]
/<>/build/./prev-gcc/gnat1(back_end__call_back_end+0x1b0)[0x9e8d40]
/<>/build/./prev-gcc/gnat1(_ada_gnat1drv+0x897)[0x9e9ba7]
/<>/build/./prev-gcc/gnat1[0x6c866d]
/<>/build/./prev-gcc/gnat1[0xd7920f]
/<>/build/./prev-gcc/gnat1(_ZN6toplev4mainEiPPc+0x6ef)[0x6ac8bf]
/<>/build/./prev-gcc/gnat1(main+0x27)[0x6aec37]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f4945ef13f1]
/<>/build/./prev-gcc/gnat1(_start+0x2a)[0x6af02a]
=== Memory map: 
0040-01df1000 r-xp  fd:01 530541
/<>/build/prev-gcc/gnat1
01ff-01ff9000 r--p 019f fd:01 530541
/<>/build/prev-gcc/gnat1
01ff9000-02007000 rw-p 019f9000 fd:01 530541
/<>/build/prev-gcc/gnat1
02007000-0267f000 rw-p  00:00 0 
02b53000-02cc2000 rw-p  00:00 0  [heap]
7f4945933000-7f4945949000 r-xp  fd:01 529904
/<>/build/prev-gcc/libgcc_s.so.1
7f4945949000-7f4945b48000 ---p 00016000 fd:01 529904
/<>/build/prev-gcc/libgcc_s.so.1
7f4945b48000-7f4945b49000 r--p 00015000 fd:01 529904
/<>/build/prev-gcc/libgcc_s.so.1
7f4945b49000-7f4945b4a000 rw-p 00016000 fd:01 529904
/<>/build/prev-gcc/libgcc_s.so.1
7f4945b4a000-7f4945b63000 rw-p  00:00 0 
7f4945cd1000-7f4945ed1000 rw-p  00:00 0 
7f4945ed1000-7f494608e000 r-xp  fd:01 257285
/lib/x86_64-linux-gnu/libc-2.24.so
7f494608e000-7f494628e000 ---p 001bd000 fd:01 257285
/lib/x86_64-linux-gnu/libc-2.24.so
7f494628e000-7f4946292000 r--p 001bd000 fd:01 257285
/lib/x86_64-linux-gnu/libc-2.24.so
7f4946292000-7f4946294000 rw-p 001c1000 fd:01 257285
/lib/x86_64-linux-gnu/libc-2.24.so
7f4946294000-7f4946298000 rw-p  00:00 0 
7f4946298000-7f49463a r-xp  fd:01 257184
/lib/x86_64-linux-gnu/libm-2.24.so
7f49463a-7f494659f000 ---p 00108000 fd:01 257184
/lib/x86_64-linux-gnu/libm-2.24.so
7f494659f000-7f49465a r--p 00107000 fd:01 257184
/lib/x86_64-linux-gnu/libm-2.24.so
7f49465a-7f49465a1000 rw-p 00108000 fd:01 257184
/lib/x86_64-linux-gnu/libm-2.24.so
7f49465a1000-7f49465ba000 r-xp  fd:01 257301
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f49465ba000-7f49467b9000 ---p 00019000 fd:01 257301
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f49467b9000-7f49467ba000 r--p 00018000 fd:01 257301
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f49467ba000-7f49467bb000 rw-p 00019000 fd:01 257301
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f49467bb000-7f49467be000 r-xp  fd:01 257282
/lib/x86_64-linux-gnu/libdl-2.24.so
7f49467be000-7f49469bd000 ---p 3000 fd:01 257282
/lib/x86_64-linux-gnu/libdl-2.24.so
7f49469bd000-7f49469be000 r--p 2000 fd:0