https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #9 from Segher Boessenkool ---
Yeah exactly... so I'm conflicted whether we need to backport this or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #8 from Jakub Jelinek ---
It is probably latent there, there were major changes in the trap and
conditional trap handling in GCC 7, so we likely don't have a testcase right
now that would ICE in 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #7 from Segher Boessenkool ---
Is it fixed? Can this not happen on GCC 6?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Wed Mar 29 20:53:59 2017
New Revision: 246575
URL: https://gcc.gnu.org/viewcvs?rev=246575=gcc=rev
Log:
combine: Fix PR80233
If combine has added an unconditional trap there will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #4 from Jakub Jelinek ---
But only at runtime, it is fine if it is never executed. So I think it is
still ice-on-valid-code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
Segher Boessenkool changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #2 from Segher Boessenkool ---
How about this patch instead?
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1250,7 +1250,8 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
continue;
while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
10 matches
Mail list logo
