On 1/24/13 10:48 AM, Tom Lane wrote:
> The fundamental problem here is that the compiler, unless told otherwise
> by a compilation switch, believes it is entitled to assume that no
> integer overflow will happen anywhere in the program. Therefore, any
> error check that is looking for overflow *should* get optimized away.
> The only reason the compiler would fail to do that is if its optimizer
> isn't quite smart enough to prove that the code is testing for an
> overflow condition. So what you are proposing here is merely the next
> move in an arms race with the compiler writers, and it will surely
> break again in a future generation of compilers. Or even if these
> particular trouble spots don't break, something else will. The only
> reliable solution is to not let the compiler make that type of
> assumption.
What I am proposing here is the opposite: _not_ to enter an arm race
with the compiler writers. Instead, make the code conform to the C
standard, something both sides can agree on.
Particularly, avoid using (signed) overflowed results to detect
overflows, which the C standard clearly specifies as undefined
behavior and many compilers are actively exploiting.
We could use either unsigned overflows (which is well defined) or
precondition testing (like `x > INT_MAX - y' in the patches).
> So I think we should just reject all of these, and instead fix configure
> to make sure it turns on icc's equivalent of -fwrapv.
While I agree it's better to turn on icc's -fno-strict-overflow as a
workaround, the fundamental problem here is that we are _not_
programming in the C language. Rather, we are programming in some
C-with-signed-wrapraround dialect.
The worst part of this C dialect is that it has never been specified
clearly what it means by "signed wraparound":
gcc's -fwrapv assumes signed wraparound for add/sub/mul, but not for
div (e.g., INT_MIN/-1 traps on x86) nor shift (e.g., 1<<32 produces
undef with clang).
clang's -fwrapv also assumes workaround for pointer arithmetic, while
gcc's does not.
I have no idea what icc and pathscale's -fno-strict-overflow option
does (probably the closest thing to -fwrapv). Sometimes it prevents
such checks from being optimized away, sometimes it doesn't.
Anyway, it would not be surprising if future C compilers break this
dialect again. But they shouldn't break standard-conforming code.
- xi