Florian Weimer wrote:
> * Andrew Haley:
>
>>> I wouldn't rule it out. Just use -fwrapv (perhaps after benchmarking
>>> to make sure that it doesn't make a difference). Other compilers will
>>> have similar switches.
>> This is bad advice. -fwrapv suppresses loop optimizations.
>
> Some loop optimizations perhaps, which are likely not to be relevant
> for the code base in the question.
Hmm...
>> Given that it's not difficult to detect overflow with perfectly
>> compliant code, there's no point.
>
> The fully compliant solution has an additional performance overhead
> compared to the one that assumes -fwrapv. Instead of -fwrapv, you can
> rely on additional guarantees from the documentation, but for someone
> that ships code to be compiled with unknown GCC versions, this might
> not be the best solution.
The test was, if I recall correctly
x = a + b;
if ((x ^ a) & (x ^ b)) < 0)
all you have to do is convert everything to unsigned values, then
ux = ua + ub;
if ((ux ^ ua) & (ux ^ ub)) & (unsigned)INT_MIN))
goto deal_with_overflow;
// we now know there is no overflow
x = ux;
which is exactly the same test as before, but perfectly compliant.
Andrew.
