Hi!
On Mon, Sep 23, 2013 at 05:26:13PM -0700, Cong Hou wrote:
Missing ChangeLog entry.
> --- gcc/testsuite/gcc.dg/alias-14.c (revision 0)
> +++ gcc/testsuite/gcc.dg/alias-14.c (revision 0)
Vectorizer tests should go into gcc.dg/vect/ instead, or, if they are
for a single target (but there is no reason why this should be a single
target), into gcc.target/<target>/.
> --- gcc/fold-const.c (revision 202662)
> +++ gcc/fold-const.c (working copy)
> @@ -2693,8 +2693,9 @@ operand_equal_p (const_tree arg0, const_
> && operand_equal_p (TYPE_SIZE (TREE_TYPE (arg0)),
> TYPE_SIZE (TREE_TYPE (arg1)), flags)))
> && types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
> - && (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg0, 1)))
> - == TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg1, 1))))
> + && types_compatible_p (
> + TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg0, 1))),
> + TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg1, 1))))
> && OP_SAME (0) && OP_SAME (1));
This looks wrong. types_compatible_p will happily return true say
for unsigned long and unsigned long long types on x86_64, because
they are both integral types with the same precision, but the second
argument of MEM_REF contains aliasing information, where the distinction
between the two is important.
So, while == comparison of main variant is too strict, types_compatible_p
is too weak, so I guess you need to write a new predicate that will either
handle the == and a few special cases that are safe to be handled, or
look for what exactly we use the type of the second MEM_REF argument
and check those properties. We certainly need that
get_deref_alias_set_1 and get_deref_alias_set return the same values
for both the types, but whether that is the only information we are using,
not sure, CCing Richard.
Jakub
