http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
Jeffrey Walton <noloader at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |noloader at gmail dot com
--- Comment #4 from Jeffrey Walton <noloader at gmail dot com> 2011-07-23
20:47:55 UTC ---
(In reply to comment #1)
> Integer overflow is undefined. You have to check before the fact, or compile
> with -fwrapv.
I'm probably spinning wheels here, but checking 'a priori' is a bit ridiculous.
Though the result is undefined, it seems to me the operation prior to the
overflow (or the cause of the overflow) is still valid. Section 3.4.3 does not
claim an operation which results in overflow is itself an 'undefined'
operation. You don't get the 'undefined behavior' (ie, undefined result) until
you perform the operation.
CPUs which use 2s compliment representations are usually well equipped to deal
with overflow and carry. I would claim a result which overflows is actually
predictable and repeatable. Fortunately, CPU manufacturers have not taken the
'ignore the problem' approach taken by ISO/IEC.
