http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49543
--- Comment #3 from Alexander Carmeli <acarmeli at mathworks dot com> 2011-06-27 18:40:25 UTC --- Andrew, You are correct about the standard not defining the result. Similar behavior was fixed before (see bug 36300 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300) I think this is still a bug, for 3 reasons: 1. the standard also defines the subtraction operation and its result to be 32-bit. The compiler is not free to up-cast it prematurely to a bigger size for optimization purposes. This was the same in 36300. 2. Relying on overflow behavior of 2's complement machines is extremely popular. Having the same expression behave differently in folded and unfolded expressions can lead to many unexpected behaviors. In addition: 2.1. Unoptimized code misbehaves, optimized code is well behaved - this is unexpected. 2.2. The C++ compiler does generate the expected numerical behavior under all conditions, without -fwrapv. 3. In my opinion, -pedantic should not affect compiler semantics. It should only control warning messages (correct me if I got this wrong). As for the result being undefined (value, not size), the standard primarily keeps the options open for non-2's complement machines and machines with non-traditional logic.
