[Bug middle-end/12963] Wrong and misleading warning encourages writing non-portable code

[qrczak at knm dot org dot pl]

------- Additional Comments From qrczak at knm dot org dot pl  2005-03-20 19:10 -------
> Better than that the availability of something like
> #pragma expected-warning line WARNING-NAME
> might remove the warning generated by the following line labeling it as checked,
> expected and/or unavoidable.

This would not help in my case because it's a regular type-generic C macro, not
generated code. The line number of the macro definition is not stable (changes
as surrounding code evolves), and it makes no sense to mark all its invocations.

>From my point of view a perfect solution would be making this obvious workaround
working:

int test(int x) {
   if ((long long)x <= 0x123456789ABCLL) return 1;
   else return 0;
}

There should be no warning if the lhs is cast to the wider type. GCC seems to be
inferring that the range of possible values of (long long)x is the range of int.
The runtime comparison is eliminated, which is good; this implies that the
warning should not be tied to the comparison being eliminated.

I'm not judging whether the warning should be emitted at all. Maybe it should be
removed altogether; after all, it's not guaranteed to be redundant on all
platforms. It definitely should not be emitted by default, especially without
any warning options, especially if the cast suggests that the programmer is
aware of it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963