tree_ssa_useless_type_conversion is too optimistic
Richard Guenther
richard.guenther@gmail.com
Sun May 15 13:18:00 GMT 2005
On 5/15/05, Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> wrote:
>
> In fact, tree_ssa_useless_type_conversion_1 contradicts itself if given
> the two (C language) pointer types "char *" and "const char *". Asking
> the langhook if they are compatible, it says no. But then in the
> section that reads
>
> /* Pointers and references are equivalent once we get to GENERIC,
> so strip conversions that just switch between them. */
> else if (POINTER_TYPE_P (inner_type)
> && POINTER_TYPE_P (outer_type)
> && TYPE_REF_CAN_ALIAS_ALL (inner_type)
> == TYPE_REF_CAN_ALIAS_ALL (outer_type)
> && lang_hooks.types_compatible_p (TREE_TYPE (inner_type),
> TREE_TYPE (outer_type)))
> return true;
Note that if the above only would apply to the C++ FE (suppose no
other frontends use REFERENCE_TYPE), the C++ langhook contains
/* Once we get to the middle-end, references and pointers are
interchangeable. FIXME should we try to replace all references with
pointers? */
if (POINTER_TYPE_P (x) && POINTER_TYPE_P (y)
&& TYPE_MODE (x) == TYPE_MODE (y)
&& TYPE_REF_CAN_ALIAS_ALL (x) == TYPE_REF_CAN_ALIAS_ALL (y)
&& same_type_p (TREE_TYPE (x), TREE_TYPE (y)))
return 1;
which is _not_ the same as the test above - it uses same_type_p, while
the code in tree_ssa_useless_type_conversion_1 ends up using
same_type_ignoring_top_level_qualifiers_p from the C++ langhook:
int
cxx_types_compatible_p (tree x, tree y)
{
if (same_type_ignoring_top_level_qualifiers_p (x, y))
return 1;
/* Once we get to the middle-end, references and pointers are
So maybe the C++ FE is supposed to handle the reference vs. pointer
stuff itself via the second check in tree_ssa_useless_type_conversion_1,
but deleting the (broader) check from tree_ssa_useless_type_conversion_1
makes temp1.C and the sra test fail exactly because this broader check.
(I wonder what happens if we change same_type_p to
same_type_ignoring_top_level_qualifiers_p in the langhook).
Richard.
More information about the Gcc
mailing list