https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Josh Triplett from comment #2) > That's a fair point. Perhaps it should go into a separate optimization > option, then, though it still seems in the spirit of -Ofast. (If overflow > is a concern, the application would hopefully be checking for that > separately; GCC also already has various optimizations that assume overflow > cannot occur.) The code might look like: return (double)lsym + lbits + dsym + (double)dbits; (we don't see the difference) that is, the application is very explicitly using double, precisely to avoid integer overflow issues. Assuming that no overflow happens in test2 is normal, it is guaranteed by the standard. Assuming that with test1 the integers are small enough that if we reorder things no overflow will happen... Well maybe someone else will be more optimistic than I am. Maybe if you could restrict it to the case where VRP information guarantees that there is no overflow? That might be rare enough that it won't matter to you though :-(
