http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
This has gone latent. Regardless it's relatively easy to fix things up in
combine -- which does similar kinds of things when it's able to collapse a
conditional jump to an unconditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Always considering trap-if as ending a BB appears to be a bit of a rathole.
Every time I squash one issue, another raises its head.
A little unexpected I'd say, what kind of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
OK, making a conditional no-return call into an unconditional no-return call
would have the same problem. Ugh.
The problem I see where is we're going to have to run some kind of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
The problem I see where is we're going to have to run some kind of cleanup
pass after each RTL pass that might make these transformations (cse, gcse,
cprop, combine and I'm sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #5 from Jeffrey A. Law law at redhat dot com ---
Always considering trap-if as ending a BB appears to be a bit of a rathole.
Every time I squash one issue, another raises its head.
I did find that combine.c already has some bits to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Now insn 24 is an unconditional trap and is considered a control flow
altering insn (see Eric's change for PR29841). Since we have a control flow
altering insn in the middle of
10 matches
Mail list logo