http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-12-12
10:20:03 UTC ---
>Sorry it underflows.
No, conversion does not have any overflow/underflow in it.
>void my_func(unsigned short a, unsigned short c)
>{
> unsigned int b;
>
> b = a * c;
There is no overflow here since this unsigned integers wrap and don't overflow.
> Yes, but the doesn't the C spec define the overflow as undefined, rather
> then the entire program?
No it is a runtime undefined behavior rather than the result being undefined.
> rather that gcc makes assumptions about this behavior that _can_ turn out to
> be not true.
But assumptions? Since it is undefined behavior, it does not matter because
GCC can make different assumptions in when it feels like.
Unless you can give a testcase that does not depend on undefined behavior, it
is hard to prove GCC is doing something wrong. -fwrapv can be used to define
signed integer overflow as wrapping.
See http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Integers-implementation.html
for how the conversion is implementation defined behavior:
> # The result of, or the signal raised by, converting an integer to a signed
> integer type when the value cannot be represented in an object of that type
> (C90 6.2.1.2, C99 6.3.1.3).
> 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.
Conversions are never causes an overflow rather it causes an implementation
defined behavior in some cases.
