This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Warning patrol: a question.
- To: gcc at gcc dot gnu dot org
- Subject: Warning patrol: a question.
- From: Jan van Male <jan dot vanmale at fenk dot wau dot nl>
- Date: Wed, 27 Jun 2001 18:40:22 +0200
- Reply-To: jan dot vanmale at fenk dot wau dot nl
Hi,
I need some advise on this before proceeding.
There are about 30 warnings in the bootstrap of the type
warning: comparison between signed and unsigned
which are related to shift instructions. Typically, the offending code
looks similar to
INTVAL (XEXP (op0, 1)) == GET_MODE_BITSIZE (mode) - 1)
where we know that op0 is a shift instruction. Therefore,
INTVAL (XEXP (op0, 1))
should always be a positive integer. Otherwise the shift instruction is
undefined. So the natural fix to eliminate the warning is to add a cast to
unsigned.
However, it doesn't seem safe to assume that INTVAL (XEXP (op0, 1)) is positive
since I found this code in combine.c (simplify_shift_const):
/* If we were given an invalid count, don't do anything except exactly
what was requested. */
if (input_count < 0 || input_count > (int) GET_MODE_BITSIZE (mode))
{
if (x)
return x;
return gen_rtx_fmt_ee (code, mode, varop, GEN_INT (input_count));
}
where `input_count' represents INTVAL (XEXP (op0, 1)) from the above
example.
I don't know why this code is here. I see three possibilities.
1) We are just being carefull, this code is not necessary.
2) INPUT_COUNT is sometimes negative for a good reason, some
other code in the compiler relies on this.
3) Occasionally, INPUT_COUNT is negative but this really is a bug.
The above code is needed to cover it up.
In case of 1) or 3) I will try to rip out this test and see what breaks.
In case of 2) this is clearly useless.
Or would you advise me not to walk on these paths since it will open a
huge can of worms?
jan