I just committed the following patch to google/4_8 as 211279. This
fixes a test failure with my backport of tree-sra fix r211180 from
trunk.
It turns out that the bug I fixed affected this test case, but because
the dumping format is slightly different between google/4_8 and both
google/4_9 and trunk, it didn't show up as a test failure for
either google/4_9 or trunk.
Essentially, after my fix, both in google/4_8 and google/4_9 (and
presumably trunk), I am getting more output in the eipa_sra dump
output. Looks like we in fact were previously not properly updating a
recursive call due to this same issue that I was fixing, although it
didn't manifest as an ICE like in the case I fixed. With the fix, we
now properly update a recursive call being optimized by SRA. The test
case is expecting to see exactly one occurrence of "foo " in the dump
output. In google/4_8, one of the new dump lines matches because it
looks like:
Adjusting call (0 -> 2) foo -> foo.isra.0
In google/4_9 and trunk, the additional dump lines don't match because
the node's order number is being printed after the name:
Adjusting call foo/0 -> foo.isra.0/2
2014-06-05 Teresa Johnson <tejohn...@google.com>
* testsuite/gcc.dg/ipa/ipa-sra-6.c: Update to handle
recent tree-sra.c fix.
Index: testsuite/gcc.dg/ipa/ipa-sra-6.c
===================================================================
--- testsuite/gcc.dg/ipa/ipa-sra-6.c (revision 210862)
+++ testsuite/gcc.dg/ipa/ipa-sra-6.c (working copy)
@@ -30,5 +30,5 @@ int main (int argc, char *argv[])
return foo (&cow, 0);
}
-/* { dg-final { scan-tree-dump-times "foo " 1 "eipa_sra" } } */
+/* { dg-final { scan-tree-dump-times "foo " 2 "eipa_sra" } } */
/* { dg-final { cleanup-tree-dump "eipa_sra" } } */
Teresa
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
