[Bug rtl-optimization/48580] missed optimization: integer overflow checks

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-04-12 21:09:53 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
> 
> --- Comment #4 from Zack Weinberg <zackw at panix dot com> 2011-04-12 21:03:01 UTC ---
> On Tue, Apr 12, 2011 at 1:52 PM, joseph at codesourcery dot com
> <gcc-bugzilla@gcc.gnu.org> wrote:
> >> In the code that this is cut down from, both arguments are known to be strictly
> >> positive, but neither is constant.  (They're only signed for historical
> >> reasons, I think, but it would be a huge amount of work to change that.)
> >
> > My point in noting the need for the integers to be positive was really
> > that unless the compiler knows they are positive, the transformation
> > you're asking for appears to be incorrect - the semantics of your function
> > are that a product with either term 0 counts as overflowing, but using a
> > processor overflow flag would report it as not overflowing.
> 
> Well, if the compiler didn't know that, it could still use the
> overflow flag plus an extra test for either input operand being zero,
> couldn't it?  The C idiom has to test for a zero result, because e.g.
> 0x4000_0000U * 16 wraps to zero.

Yes (a check for them being <= 0, that is; I think that function will 
report any case with negative operands as overflowing as well).