This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: When to ingore signed vs. unsigned comparison?
- From: Paul Schlie <schlie at comcast dot net>
- To: Joern RENNECKE <joern dot rennecke at st dot com>,Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 08 Feb 2005 12:43:04 -0500
- Subject: Re: When to ingore signed vs. unsigned comparison?
> Joern RENNECKE wrote:
>
>> Richard Guenther wrote:
>>
>> The question simplified boils down to: given two trees a and b
>> with one of them being an (signed or unsigned) integer constant,
>> when and how do I convert the integer constant to the type of
>> the other tree? The simplest case would be f.i. int i and 5U
>> - how do I check that it is legal to convert 5U to int, and how
>> do I do this?
>
>> Using fold_convert_const_int_from_int and checking TREE_CONSTANT_OVERFLOW
>> on the result doesn't work - I get 0fffffffb from -5 to unsinged
>> and no overflow set.
>
> Conversions from signed to unsigned cause no overflow, so I think
> for these conversions, you have to do the range check separately.
> If you don't convert to a smaller mode, that should be just
> a check that the value is greater than or equal to zero.
>
> OTOH, unsigned->signed conversions should cause overflow when the
> destination type can't represent the value.
[ const unsigned => signed should not generate overflow if the value's
is represent-able in it's singed counterpart, i.e. no warnings! ]
As a generalization, would only expect a comparison ambiguity warning
for the comparison between any two arbitrary trees a and b iff:
(typeof(b))a <comparison> (typeof(a))a
may be ambiguous (assuming const type casts are suppressed, as variable
types can't be converted to const, unless in a declaration), thereby:
(int)a == (const unsigned)1
is only ambiguous iff:
(int)a == (int)1
Where as "a"'s type can't be cast (const ...), so preserved; and
a (const unsigned)1 may be converted to (int) with no ambiguity;
the comparison is unambiguous, and should generate no warnings.
---
Which would be consistent with the comparison of two arbitrary values,
both before and/or after assignment to each other, thereby:
((type_a)((type_b)b) == (type_b)b)
As one would expect:
type_a a = something, b = (type_b)value
((a <compare> b) == (a <compare> (type_b)value))