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]

Warning patrol: a question.


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


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