https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Wed Feb 17 20:45:15 2016
New Revision: 233506
URL: https://gcc.gnu.org/viewcvs?rev=233506&root=gcc&view=rev
Log:
PR c++/69842
* method.c (forward_parm): Split out from...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #7 from Manuel López-Ibáñez ---
Richard, perhaps a less aggressive -Wunreachable-code could be implemented just
after (or while) building the control flow graph?
It would not try to be smart with constant propagation or guessing bran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
--- Comment #6 from Manuel López-Ibáñez ---
Other testcases:
int baz()
{
while(1) {
break;
return 5; // dead
}
do {
continue;
return 6; // dead
} while(0);
return 1;
}
int bax()
{
while(1) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 17 22:27:24 2016
New Revision: 233508
URL: https://gcc.gnu.org/viewcvs?rev=233508&root=gcc&view=rev
Log:
PR c++/69850
* gimplify.c (gimplify_cond_expr): Call gimpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
--- Comment #8 from Thomas Koenig ---
The fix for 47674 wasn't complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #5 from Dominik Vogt ---
@Matthias: So far it only happens for me when building a gcc rpm from source on
a (very slow VM), but not when compiling the same sources. Is there anything
special about your build machine or environment on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69856
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #8 from Thomas Preud'homme ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #12 from Alexander Cherepanov ---
Seems to be fixed, thanks! I've tried several variations, ok too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67767
--- Comment #2 from zerotype at yahoo dot com ---
This can be worked around by using:
[[gnu::cold]] [[gnu::noreturn]]
instead of
[[gnu::cold, gnu::noreturn]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69862
Bug ID: 69862
Summary: STL containers not using allocator's definition of
pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:07:55 2016
New Revision: 233512
URL: https://gcc.gnu.org/viewcvs?rev=233512&root=gcc&view=rev
Log:
PR c++/68679
* decl2.c (reset_type_linkage_2): Look throug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:08:02 2016
New Revision: 233513
URL: https://gcc.gnu.org/viewcvs?rev=233513&root=gcc&view=rev
Log:
PR c++/68585
* constexpr.c (cxx_eval_bare_aggregate): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:08:09 2016
New Revision: 233514
URL: https://gcc.gnu.org/viewcvs?rev=233514&root=gcc&view=rev
Log:
PR c++/65985
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #42 from Thomas Koenig ---
(In reply to Wilco from comment #41)
> Yes, but it was suggested that -std=legacy wasn't the right flag in comment
> 35...
What -std=legacy mostly does is to allow extensioms, not to accept
code which was
101 - 122 of 122 matches
Mail list logo
