http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571
Bug ID: 59571
Summary: [C++11] ICE when casting inside static member
constexpr brace initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #2 from H.J. Lu ---
254.gap in SPEC CPU 2K is also failed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570
Bug ID: 59570
Summary: Warning for semicolon trailing closing curly brackets
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #1 from H.J. Lu ---
Created attachment 31494
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31494&action=edit
A testcase
[hjl@gnu-mic-2 0001]$
/export/project/git/gcc-regression/master/206150/usr/bin/gcc -S -O3
-funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
Bug ID: 59569
Summary: [4.9 Regression] r206148 causes internal compiler
error: in vect_create_destination_var, at
tree-vect-data-refs.c:4294
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #10 from Dominique d'Humieres ---
> Hello,
> thank you for the hotfix that repaired switch/case missing return value.
Nothing has been committed yet to fix darwin bootstrap!-(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #27 from janus at gcc dot gnu.org ---
>From http://gcc.gnu.org/ml/fortran/2013-12/msg00104.html ...
Currently missing are:
a) Finalization of the LHS during intrinsic assignment:
b) Finalization of functions results after their use
c)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #9 from Martin Liška ---
Hello,
thank you for the hotfix that repaired switch/case missing return value.
Actually I was told by Jan to reproduce the functionality from varasm.c that I
was able to bootstrap and test.
The idea of re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
--- Comment #6 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #5)
> Maybe I'm missing something here. We have this immediately prior to IRA:
>
> ISTM that we want (reg 86) to prefer di and (reg 87) to prefer ax by way of
> t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #18 from Jeffrey A. Law ---
Whoops, message for Richi was meant for a different BZ.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #17 from Jeffrey A. Law ---
Dominique, thanks for verifying that 58746 is a duplicate. I was wondering
about that.
Richi, we've known for a long time (since the early 90s) that running CSE soon
after loop unrolling is profitable. So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #4 from Physeterm at yahoo dot com ---
Created attachment 31493
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31493&action=edit
make command
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #3 from Physeterm at yahoo dot com ---
Created attachment 31492
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31492&action=edit
output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #2 from Physeterm at yahoo dot com ---
Created attachment 31491
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31491&action=edit
input test file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
--- Comment #1 from Physeterm at yahoo dot com ---
Created attachment 31490
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31490&action=edit
test program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #16 from Dominique d'Humieres ---
> For the FE change, I guess most important are benchmark results,
> doesn't it slow down important benchmarks?
AFAICT the answer is not at least for the gfortran test suite and the
polyhedron ones
(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
Bug ID: 59568
Summary: complex type operator>> does not set eofbit for input
streams.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #15 from Dominique d'Humieres ---
*** Bug 58746 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #14 from Jeffrey A. Law ---
So a quick prototype which reuses the infrastructure from the
phi-only-propagator cleans things up quite nicely.
Given this block after substitute_and_fold does its thing:
:
ubound.0_3 = 0;
size.1_4 = ubou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #40 from dave.anglin at bell dot net ---
On 12/19/2013 5:53 PM, John David Anglin wrote:
> Rechecking status on the arm box.
Problem is still there:
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:58:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> Isn't that effectively a duplicate of the P1 regression PR57904?
Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9
does not s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Summary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 16:34:21 2013
New Revision: 206153
URL: http://gcc.gnu.org/viewcvs?rev=206153&root=gcc&view=rev
Log:
PR c++/59255
Backported from mainline
2013-08-19 Dehao Chen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 16:32:21 2013
New Revision: 206152
URL: http://gcc.gnu.org/viewcvs?rev=206152&root=gcc&view=rev
Log:
PR c++/59255
* g++.dg/tree-prof/pr59255.C: New test.
Added:
tru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
--- Comment #3 from gdlxn at us dot ibm.com ---
Richard and Jakub - Thanks for the quick response and explanation. I was able
to use the -nostdinc option to suppress the automatic inclusion of
, which eliminates the unwanted comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #4 from Dominique d'Humieres ---
> I believe that is the only reason for the different number of vector
> additions.
I don't think the number of packed double operations is changed, only the
number of occurrences of the scanned regul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #10 from Richard Biener ---
Testing
Index: gimplify.c
===
--- gimplify.c (revision 205891)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59315
Jakub Jelinek changed:
What|Removed |Added
Target|*-*-solaris2.* |
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59544
--- Comment #1 from meibf at gcc dot gnu.org ---
Author: meibf
Date: Fri Dec 20 13:46:01 2013
New Revision: 206148
URL: http://gcc.gnu.org/viewcvs?rev=206148&root=gcc&view=rev
Log:
2013-12-20 Bingfeng Mei
PR tree-optimization/59544
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #3 from Jakub Jelinek ---
True, I guess adding -mtune=generic doesn't hurt though, it will be still
broken with --target_board=unix/-mtune=core2 or similar testing, but at least
it will FAIL less often. For core* tuning the difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 20 13:07:10 2013
New Revision: 206147
URL: http://gcc.gnu.org/viewcvs?rev=206147&root=gcc&view=rev
Log:
PR tree-optimization/59413
* gcc.c-torture/execute/pr59413.c: New t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #5)
> It is fixed by r205884. We can add the testcase and close it.
FWIW, it is also introduced by r204516.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote:
> In particular, are the following well-defined according the standard or they
> have undefined behavior?
In both cases, you are accessi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #8 from Jakub Jelinek ---
Ah, my fault then, terribly sorry, I've simplified the testcase a little bit
(removed the typedef and used unsigned int instead). Apparently for the
reproduction it is important that the c variable uses some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Jascha Wetzel changed:
What|Removed |Added
Attachment #31488|compile simply with "g++|reproducer
description|"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Jascha Wetzel changed:
What|Removed |Added
Attachment #31486|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567
Bug ID: 59567
Summary: Incorrect error 'was not declared in this scope'
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
--- Comment #6 from Jakub Jelinek ---
Weird, I still get exactly the same code (except for gcc version string)
between pre-r205884 and post-r205884. So, what exact differences are you
seeing on the testcase, and with -fdump-tree-all -da starting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #8 from Dominique d'Humieres ---
> > could someone please point me at the original post for this patch?
>
> I have the same question.
I have finally found the answer: final patch at
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01368.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59564
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #5 from bin.cheng ---
For the offending loop:
:
:
# b.4_30 = PHI
# prephitmp_28 = PHI
# b_lsm.11_13 = PHI
# ivtmp_46 = PHI
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59565
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #13 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #12)
> But you can always create testcases (in C/C++ etc.) that will hit this
> warning, so while the FE change is possible, we need to do something either
> about the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59510
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Markus Trippelsdorf from comment #5)
>
> > gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
> > 9223372036854775806 cannot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541
--- Comment #7 from Dominique d'Humieres ---
Note that on x86_64-apple-darwin10 the test
gcc.dg/tree-prof/cold_partition_label.c has started to fail (compilation,
-fprofile-use -D_PROFILE_USE) between r204856 (OK) and r205324 (fail). This is
fixe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811
--- Comment #9 from __vic ---
Is there any progress and/or solid plan? The last available version of G++ for
HP-UX is 4.7.1 (here
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=2a08725cc2f02110725cc2f0211
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
--- Comment #6 from Jakub Jelinek ---
(In reply to Markus Trippelsdorf from comment #5)
> Thanks Jakub, it looks much better now. What is left are mostly left shifts
> of negative values:
>
> gcc/combine.c:11865:14: runtime error: left shift of n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #12 from Jakub Jelinek ---
(In reply to Dominique d'Humieres from comment #11)
> With the patch in comment 9, gfortran.dg/class_48.f90 no longer fails and I
> don't see any regression. The warning for the test in pr58746 comment 2 is
>
64 matches
Mail list logo
