Bug in int_fits_type_p

[Roger Sayle <roger at eyesopen dot com>]

Hi Richard and Olivier,

Whilst working on a regression fix concerning TREE_CONSTANT_OVERFLOW,
I've discovered a bug in the middle-end that appears to have been
introduced by the change:

2003-04-14  Olivier Hainque <hainque@act-europe.fr>

        * tree.c (int_fits_type_p): Extract generic checks from the case
        of constant type bounds. Refine the checks against constant type
        bounds to allow for possible decisions against each of these bounds
        without requiring both bounds to be constant.
        (tree_int_cst_msb): Put back.
        * tree.h (tree_int_cst_msb): Likewise.


The problem concerns the following logic in tree.c's int_fits_type_p:

  /* Perform some generic filtering first, which may allow making a
     decision even if the bounds are not constant.  First, negative
     integers never fit in unsigned types, */
  if ((TYPE_UNSIGNED (type) && tree_int_cst_sgn (c) < 0)
      /* Also, unsigned integers with top bit set never fit signed types.  */
      || (! TYPE_UNSIGNED (type)
          && TYPE_UNSIGNED (TREE_TYPE (c)) && tree_int_cst_msb (c)))
    return 0;

Specifically, the second "Also" clause and it's use of tree_int_cst_msb.
Unfortunately, this leads us to believe that an unsigned QImode 255,
won't fit in an a signed SImode type.  The call to tree_int_cst_msb,
checks for the most significant bit in C's type, which in this case is
set but in a mode much narrower than TYPE's mode.

Prior to the change cited above, the original code contained the
test "TREE_INT_CST_HIGH (c) < 0" which tested the high-bit of the
host constant (typically DImode).  Olivier's path introduced the
new function tree_int_cst_msb, and modified this clause, thereby
changing its behaviour.


Clearly, this change was introduced to address some aspect of the
Ada front-end's non-constant type minval and maxval, which is why
I now seek advice on how best to resolve this issue.

My first proposal would be to remove the call to tree_int_cst_msb,
[and as this is that function's only use also the implementation
itself and the prototype in tree.h], and go back to the original
TREE_INT_CST_HIGH (c) < 0".  This would resolve the problem I'm
seeing, but isn't a particularly agrressive test.

The alternate approach would be to add an additional comparison of
the precisions of both types, something along the lines of:

    && TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (c))

The issue here is that I'm unclear on whether TYPE_PRECISION can
safely be used like this here for the Ada's variable-range types?


Any advice (or even fixing the problem) would be much appreciated.
Many thanks in advance,

Roger
--