https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #30 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Matthias Kretz (Vir) from comment #29)
> Right. But if that's the case wouldn't a warning about the unexpected
> promotion be useful? (which -Wsign-compare happens to provide)
Yes, and FYI, there were such platform-dependent bugs in GNU MPFR in the past
involving additions or subtractions (not comparisons). I added the following in
its README.dev file:
--------------------------------------------------------------------------
Avoid mixing signed and unsigned integer types, as this can lead signed
types to be automatically converted into unsigned types (usual arithmetic
conversions). If such a signed type contains a negative value, the result
may be incorrect on some platforms. With MPFR 2.x, this problem could
arise with mpfr_exp_t, which is signed, and mpfr_prec_t (mp_prec_t),
which was unsigned (it is now signed), meaning that in general, a cast
of a mpfr_prec_t to a mpfr_exp_t was needed.
Note that such bugs are difficult to detect because they may depend on
the platform (e.g., on LP64, 32-bit unsigned int + 64-bit long will give
a signed type, but on ILP32, 32-bit int + 32-bit unsigned long will give
an unsigned type, which may not be what is expected), but also on the
input values. So, do not rely on tests very much. However, if a test
works on 32 bits but fails on 64 bits in the extended exponent range
(or conversely), the cause may be related to the integer types (e.g. a
signness problem or an integer overflow due to different type sizes).
For instance, in MPFR, such issues were fixed in r1992 and r5588.
An example that will fail with 32-bit int and long:
long long umd(void)
{
long a = 1;
unsigned int b = 2;
return a - b;
}
--------------------------------------------------------------------------
So a warning for such operations would also be useful. But I'm not sure about
potential issues with false positives...
