https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #9 from AK ---
Are we also taking advantage of this statement in the standard:
> An iteration statement that performs no input/output operations, does not
> access volatile objects, and performs no
synchronization or atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #8 from Marc Glisse ---
At some point, we could also think of taking advantage of what the C++ standard
(for instance) says:
"[intro.progress]
The implementation may assume that any thread will eventually do one of the
following:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #7 from amker at gcc dot gnu.org ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to amker from comment #4)
> > Well, one decision needs to be made is whether such bound information should
> > be covered by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #5 from Jakub Jelinek ---
(In reply to amker from comment #4)
> Well, one decision needs to be made is whether such bound information should
> be covered by -faggressive-loop-optimizations. We already did this for
> undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #4 from amker at gcc dot gnu.org ---
Well, one decision needs to be made is whether such bound information should be
covered by -faggressive-loop-optimizations. We already did this for undefined
behavior of sign type and array bound.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #1 from Marc Glisse ---
That could be because gcc sadly refuses to optimize away infinite loops
(happens for other cases, and cddce2 dump (the pass that removes the whole
thing when the macro is defined) says "can not prove
11 matches
Mail list logo
