I am confident in the correctness of the tests I wrote for overflow for C
(gcc.dg/overflow-warn-[1234].c). This doesn't necessarily mean the
present mixture of ways of indicating that an expression of integer
constants is not an integer constant expression (for whatever combination
of reasons
On Sun, Nov 7, 2010 at 11:04 PM, Jason Merrill wrote:
> Currently, the middle end seems to use the same rules for handling constant
> overflow of integer arithmetic and conversion between integer types: set
> TREE_OVERFLOW on the INTEGER_CST if the type is signed and the value doesn't
> fit in the
On 11/07/2010 11:11 PM, Ian Lance Taylor wrote:
C99 6.2.5 paragraph 9 says "A computation involving unsigned operands
can never overflow, because a result that cannot be represented by the
resulting unsigned integer type is reduced modulo the number that is one
greater than the largest value that
Jason Merrill writes:
> So we're setting TREE_OVERFLOW inappropriately for conversion to
> signed integer types (though the front ends unset it again in cast
> context), and, more problematically, failing to set it for unsigned
> arithmetic overflow:
C99 6.2.5 paragraph 9 says "A computation inv
Currently, the middle end seems to use the same rules for handling
constant overflow of integer arithmetic and conversion between integer
types: set TREE_OVERFLOW on the INTEGER_CST if the type is signed and
the value doesn't fit in the target type. But this doesn't seem to
match the C/C++ sta
