The following reverts a bogus fix done for PR101009 and instead makes
sure we get into the same_access_functions () case when computing
the distance vector for g[1] and g[1] where the constants ended up
having different types. The generic code doesn't seem to handle
loop invariant dependences. The special case gets us both
( 0 ) and ( 1 ) as distance vectors while formerly we got ( 1 ),
which the PR101009 fix changed to ( 0 ) with bad effects on other
cases as shown in this PR.
PR tree-optimization/116768
* tree-data-ref.cc (build_classic_dist_vector_1): Revert
PR101009 change.
* tree-chrec.cc (eq_evolutions_p): Make sure (sizetype)1
and (int)1 compare equal.
* gcc.dg/torture/pr116768.c: New testcase.
(cherry picked from commit
5b5a36b122e1205449f1512bf39521b669e713ef)
--- /dev/null
+/* { dg-do run } */
+
+#define numwords 2
+
+typedef struct {
+ unsigned words[numwords];
+} Child;
+
+typedef struct {
+ Child child;
+} Parent;
+
+Parent my_or(Parent x, const Parent *y) {
+ const Child *y_child = &y->child;
+ for (int i = 0; i < numwords; i++) {
+ x.child.words[i] |= y_child->words[i];
+ }
+ return x;
+}
+
+int main() {
+ Parent bs[4];
+ __builtin_memset(bs, 0, sizeof(bs));
+
+ bs[0].child.words[0] = 1;
+ for (int i = 1; i <= 3; i++) {
+ bs[i] = my_or(bs[i], &bs[i - 1]);
+ }
+ if (bs[2].child.words[0] != 1)
+ __builtin_abort ();
+ return 0;
+}
|| TREE_CODE (chrec0) != TREE_CODE (chrec1))
return false;
- if (chrec0 == chrec1)
+ if (operand_equal_p (chrec0, chrec1, 0))
return true;
if (! types_compatible_p (TREE_TYPE (chrec0), TREE_TYPE (chrec1)))
TREE_OPERAND (chrec1, 0));
default:
- return operand_equal_p (chrec0, chrec1, 0);
+ return false;
}
}
non_affine_dependence_relation (ddr);
return false;
}
- else
- *init_b = true;
}
return true;