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