[Bug c/30475] assert(int+100 > int) optimized away

["js at linuxtv dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #53 from js at linuxtv dot org  2007-03-08 01:03 -------
I read all this and the mailing list thread with great interest,
however I think there is a fundamental flaw in the reasoning:

C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow
as "implementation-defined behaviour", which is something completely
different than "undefined behaviour".
See C90 3.11 vs. 3.18 / C99 3.4.1 vs. 3.4.3.
(3.4.1 implementation-defined behavior: "unspecified behavior where each
implementation documents how the choice is made").

And lo and behold:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Integers-implementation.html
http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Integers-implementation.html

"For conversion to a type of width N, the value is reduced modulo 2^N to be
within range of the type; no signal is raised."

(Older versions of gcc left this undocumented.)

Of course, software which relies on that is non-portable, but that's
different from being "invalid C". If it turns out that many major
C compilers use a similar implementation (which is what I expect
but have no proof of), then it would be wise if gcc would do the
same.

E.g. Sun C uses this definitions:
http://docs.sun.com/source/819-3688/c90.implementation.app.html#pgfId-998756
"When an integer is converted to a shorter signed integer, the low order bits
are copied from the longer integer to the shorter signed integer. The result
may be negative."

Anyway, gcc should behave as documented, which isn't the case at least
for gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475