64 bit mudflap failures

Andreas Krebbel krebbel1@de.ibm.com
Fri Jan 7 08:51:00 GMT 2005


Hi,

there are three new mudflap failures on s390x (64bit). I think at least one of 
them is caused by this patch:

> 2005-01-01  Roger Sayle  <roger@eyesopen.com>
>             Olivier Hainque  <hainque@act-europe.fr>
> 
>         * tree.c (int_fits_type_p): A narrower type always fits in a
>         wider one, except for negative values into unsigned types.

The variable "foo" in the following testcase is not instrumented by mudflap
because it is not marked addressable:

fail1-frag.c:

int main ()
{
  volatile int foo [10];
  foo[10] = 0;
  return 0;
}

It should be marked addressable by this code:

if (TREE_CODE (index) == INTEGER_CST
          && TYPE_DOMAIN (TREE_TYPE (array))
          && !int_fits_type_p (index, TYPE_DOMAIN (TREE_TYPE (array))))
        {
          if (!c_mark_addressable (array))
            return error_mark_node;
        }

int_fits_type_p should recognize that the index does not fit in the array index
type but it fails to do due to the following check (introduced by the patch):

int
int_fits_type_p (tree c, tree type)
{
  ...

  /* Second, narrower types always fit in wider ones.  */
  if (TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (c)))
    return 1;	


The precision of the constant's type is set to INT_TYPE_SIZE which is 32 (set in s390.h).

The precision of the index type is set in build_index_type to the precision
of sizetype which is the precision of unsigned long (64, set in set_sizetypes).

I don't say introducing that check was wrong because it seems sensible to me, but 
it unfortunately causes the mentioned failure.

Perhaps changing the precision of constants would be a solution, but I've no idea how that
would impact other code.

Bye,

-Andreas-



More information about the Gcc-patches mailing list