http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 08:28:36 UTC --- Created attachment 22979 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22979 Patch that fixes (papers over?) the bug by compensating for the unsafe assumption Here's another alternative, that does not discard the unsafe optimization, but instead attempts to make it safe. Considering that the computed trip count should only apply when the counter is exact, and that the other exit is taken at the next trip, this patch compensates for the too-low trip count by replacing the exact division by a rounded-up division, which gives us the correct trip count for this particular loop. Other cases in which we'd take another exit after more than one iteration would presumably still fail, but I don't know enough about the loop infrastructure to tell whether this possibility might arise.
