https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #26 from Bernd Edlinger ---
Author: edlinger
Date: Wed Jul 1 16:10:30 2015
New Revision: 225260
URL: https://gcc.gnu.org/viewcvs?rev=225260&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-07-01 Bernd Edlinger
PR rtl-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.3 |4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #25 from Jakub Jelinek ---
GCC 4.9.3 has been released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #24 from Eric Botcazou ---
> I agree that this is too risky to backport, but I disagree with the decision
> not to fix it on the trunk. We have plenty of time to watch for performance
> regressions and/or bugs it introduces there, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #23 from Bernd Edlinger ---
sorry, which patch are we discussing here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #22 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #21)
> > I think that the patch is clear in scope, only fixes a specific case unless
> > rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #21 from Eric Botcazou ---
> I think that the patch is clear in scope, only fixes a specific case unless
> rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
> trunk, 5.1 and 4.9.
No, the patch is way too risky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
Bernhard Kaindl changed:
What|Removed |Added
CC||bernhard.kaindl@thalesgroup