Neil Conway <neilc@samurai.com> writes:
> IMHO code that makes assumptions about overflow behavior beyond what is
> defined by the standard is asking for trouble, whether those assumptions
> are "traditional C semantics" or not. Given that -fwrapv apparently
> hurts performance *and* you've presented no evidence that we actually
> need the flag in the first place, I'm not sold on this idea...
Can you present a reasonably efficient way to test for integer overflow,
as is needed in int4pl and friends (not to mention a lot of security
checks that you yourself had a hand in adding), without making any
assumptions that the new gcc may think are illegal? ISTM that what the
spec is doing (according to Jakub's interpretation of it anyway) is
denying the existence of overflow for signed values, which is (a) silly
and (b) unhelpful.
The larger problem here, however, is exactly the same as it was with
-fno-strict-aliasing: the compiler provides no useful tools for finding
the places where your code may be broken by the new assumptions.
I'd be willing to have a go at fixing the problems if I could be certain
that we'd found them all, but what gcc is actually offering us is a game
of Russian roulette. I have better things to do with my time than to
try to find all the places we'd need to fix to have any confidence that
our code is safe without -fwrapv.
regards, tom lane