Hi, I've observed a FAILURE for gcc.dg/graphite/scop-19.c with fpic: ... FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 2 ...
In the nonpic case, d_growable_string_resize is inlined into d_growable_string_append_buffer, and we have 2 functions with a loop, wich results in two 'number of SCoPs' entries.
In the pic case, d_growable_string_resize is not inlined into d_growable_string_append_buffer (since it's not inlinable), and we have only one function with a loop, wich results in one 'number of SCoPs' entry.
This patch updates the scan-tree-dump to match the pic/nonpic behaviour. OK for trunk? Thanks, - Tom
2015-02-04 Tom de Vries <t...@codesourcery.com> * gcc.dg/graphite/scop-19.c: Fix scan-tree-dump for fpic. diff --git a/gcc/testsuite/gcc.dg/graphite/scop-19.c b/gcc/testsuite/gcc.dg/graphite/scop-19.c index 9dfc865..ab23bb4 100644 --- a/gcc/testsuite/gcc.dg/graphite/scop-19.c +++ b/gcc/testsuite/gcc.dg/graphite/scop-19.c @@ -31,6 +31,7 @@ d_growable_string_append_buffer (struct d_growable_string *dgs, if (need > dgs->alc) d_growable_string_resize (dgs, need); } -/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite"} } */ +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target nonpic } } } */ +/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! nonpic } } } } */ /* { dg-final { cleanup-tree-dump "graphite" } } */ -- 1.9.1