This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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))





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]