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

["zackw at panix dot com" <gcc-bugzilla@gcc.gnu.org>]

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.

(The original code does in fact check for x or y  <= 0 in a place
where VRP would notice; I should have said that instead of "known to
be strictly positive", sorry for any confusion.)