[Bug ada/60403] [5/6/7 Regression] fatal error, system.ads not formatted correctly

2017-02-10 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60403 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug c/79460] New: gcc fails to optimise out a simple additive loop for seemingly arbitrary numbers of iterations

2017-02-10 Thread drraph at gmail dot com
and float f(float x[]) { float p = 1.0; for (int i = 0; i < 200; i++) p += 1; return p; } both compiled in gcc 7 (20170210 snapshot) with -Ofast . In the former case (the 202 case) you get: f: movss xmm0, DWORD PTR .LC0[rip] ret .LC0: .long 1128988672

[Bug c++/79452] Provide builtin to detect compile-time execution

2017-02-10 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 Eric Fiselier changed: What|Removed |Added CC||eric at efcs dot ca --- Comment #7 from

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

2017-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/79461] New: [C++1z] ICE when capturing a variable in a lambda in a constexpr constructor

2017-02-10 Thread hafnermorris at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79461 Bug ID: 79461 Summary: [C++1z] ICE when capturing a variable in a lambda in a constexpr constructor Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: norm

[Bug target/79451] [7 Regression] ICE in expand_expr_real_2, at expr.c:9021 w/ -O3 -floop-nest-optimize

2017-02-10 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79451 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC|

[Bug target/79404] [7 Regression] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

2017-02-10 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Mileston

[Bug target/79462] New: sh: Stack smashing detected when building __ashrdi3 in libgcc

2017-02-10 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Bug ID: 79462 Summary: sh: Stack smashing detected when building __ashrdi3 in libgcc Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal

[Bug sanitizer/79341] Many Asan tests fail on s390

2017-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #44 from Jakub Jelinek --- Author: jakub Date: Fri Feb 10 23:34:49 2017 New Revision: 245350 URL: https://gcc.gnu.org/viewcvs?rev=245350&root=gcc&view=rev Log: PR sanitizer/79341 * configure.tgt (s390*-*-linux*): Don'

[Bug target/79462] sh: Stack smashing detected when building __ashrdi3 in libgcc

2017-02-10 Thread dhowells at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 --- Comment #1 from dhowells at redhat dot com --- Here's the configuration command for hosting on ppc64le: CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8

[Bug libstdc++/61582] C++11 regex memory corruption

2017-02-10 Thread P at draigBrady dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Pádraig Brady changed: What|Removed |Added CC||P at draigBrady dot com --- Comment #20

[Bug libstdc++/61582] C++11 regex memory corruption

2017-02-10 Thread timshen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 --- Comment #21 from Tim Shen --- (In reply to Pádraig Brady from comment #20) > Any status update on this. GCC7 is looming... > Thanks. Unfortunately I haven't get a chance to work on this. I plan to put up a one-line tweak on the internal stat

[Bug rtl-optimization/21182] [5/6/7 Regression] gcc can use registers but uses stack instead

2017-02-10 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #24 from Jeffrey A. Law --- Do we happen to have easy access to the pressure at the various program points? Dumping that with the points might prove fruitful in both the search for potential over-aggressive optimizations and to guide

<    1   2