http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #6 from Jeffrey Walton <noloader at gmail dot com> 2011-07-23 22:28:07 UTC --- (In reply to comment #5) > > 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. > > See http://www.airs.com/blog/archives/120 for more elaborated views. Thanks Eric - I really enjoy reading Ian and Jonathan on GCC-Users (I wish they would write a modern GCC book). I believe Ian might have overlooked one usage case (but speaking to the masses, he is spot-on). In many cases, folks are oblivious to overflow and will truck on as if nothing happened. In the "what's overflow" case, I think Ian's arguments are correct in assuming all statements are well formed and all results are well defined. The majority of folks don't code for overflow so GCC should not care either. However, there is a minority of folks who do care. I'm willing to perform an operation that will lead to overflow, but I'm not willing to use the [possibly undefined] result. In between the operation and result, I need help from GCC to efficiently determine overflow or carry. For the architectures I have worked on, this is inevitably some flags. Note that I've never worked on a sign-magnitude machine, and have no idea what the efficient methods are. I think there is a disconnect between ISO/IEC and their desire to produce portable code, secure programming, and practical implementations. Confer: ME: "I want to check the flags register on x86/x64 to determine overflow anfter an ADD or SUB operation." ISO/IEC: "What's overflow? Our abstract machines do not overflow. And a FLAGS register is not portable, so we're not making any provisions for it." Interestingly, GCC seems to add its own twist: it wants to produce optimized code. In the end, it would be a lot of help (to a minority of folks) if GCC moved from its position of "all programs do not have undefined behavior" and provided some intrinsics (where applicable) to help folks with the problem: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467 Jeff
