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-bugzi...@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).
