Neil Conway <neil.conway@gmail.com> writes:
> FWIW, I think we should aim to eventually remove the dependency on
> -fwrapv, and instead make the code correct under the semantics
> guaranteed by the C spec.
[ shrug... ] We've gone around on that before. I can't get excited
about it, and the reason is that 99% of the places where we actually
need -fwrapv behavior is in places where we are trying to test for
overflow. The need for that can't be legislated away. As an example,
in int4pl we have code like
result = arg1 + arg2;if (some-test-on-result-and-arg1-and-arg2) elog(ERROR, "overflow");
Here's the problem: if the compiler is allowed to assume that overflow
cannot happen, it is always going to be able to "prove" that the
if-test is constant false. This is inherent. Anybody claiming to
exhibit a safe way to code the overflow test is really only telling
you that today's version of their compiler isn't smart enough to make
the proof. Next year, who knows? I'm uninterested in getting into
that kind of arms race with the compiler authors. I prefer to keep
the goalposts exactly where they've been for the past forty years,
namely -fwrapv semantics.
If the compiler guys actually were serious about helping people write
code that didn't need -fwrapv, they would provide primitives for
testing for arithmetic overflow. I would be ecstatic if we could write
int4pl like this:
if (sum_overflows(arg1, arg2)) elog(ERROR, "overflow");else return arg1 + arg2;
especially since with a halfway decent compiler this sort of
construction wouldn't even require doing the addition twice ---
presumably the compiler could see that it had a common subexpression
there, and generate code that consists of one addition plus a
branch-on-overflow test. This'd be clean, readable, and far more
efficient than the hacks we have to resort to now.
Short of that, though, -fwrapv is what it's gonna be.
regards, tom lane