[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Liška --- Fixed.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #12 from Martin Liška --- Author: marxin Date: Fri Oct 26 07:23:33 2018 New Revision: 265521 URL: https://gcc.gnu.org/viewcvs?rev=265521=gcc=rev Log: Relax hash function to match equals function behavior (PR testsuite/86158). 2018-10-26 Martin Liska PR testsuite/86158 * ipa-prop.c (struct ipa_vr_ggc_hash_traits): Hash with addr_expr and not with pointers. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #11 from Martin Liška --- I have a working patch for it.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #10 from seurer at gcc dot gnu.org --- For a while the test case stopped failing (I don't know why but from the results logs it was about 25 June this year around r262009) but just recently it started again (sometime around r264987 on 6 October).
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158
--- Comment #9 from Martin Liška ---
And the integer constants are created here:
ipa-prop.c:
if (addr_nonzero)
{
tree z = build_int_cst (TREE_TYPE (arg), 0);
ipa_set_jfunc_vr (jfunc, VR_ANTI_RANGE, z, z);
}
So it explains why it was exposed by a VRP change.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #8 from Martin Liška --- Got it, if I print pointer value of streamed trees I see: BAD: Creating output block for jmpfuncs Encoding indexableas 0 Encoding indexableas 1 Encoding indexableas 2 Streaming SCC of (0x76af78a0) Streamingto jmpfuncs Streamingto jmpfuncs Encoding indexableas 3 Encoding indexableas 4 Existing SCC of (0x76ade5c8) Finished SCC of Streaming SCC of (0x76af25a0) Finished SCC of Existing SCC of (0x76af25a0) Streaming SCC of (0x76af7900) Streamingto jmpfuncs Encoding indexableas 5 Encoding indexableas 0 Finished SCC of Streaming SCC of (0x76af25b8) Finished SCC of Existing SCC of (0x76af25b8) Streaming SCC of (0x76af7940) Streamingto jmpfuncs Encoding indexableas 0 Finished SCC of Streaming SCC of (0x76ae1d20) Finished SCC of Existing SCC of (0x76ae1d20) GOOD: Creating output block for jmpfuncs Encoding indexableas 0 Encoding indexableas 1 Encoding indexableas 2 Streaming SCC of (0x76af99c0) Streamingto jmpfuncs Streamingto jmpfuncs Encoding indexableas 3 Encoding indexableas 4 Existing SCC of (0x76ade640) Finished SCC of Streaming SCC of (0x76af3690) Finished SCC of Existing SCC of (0x76af3690) Streaming SCC of (0x76af9a20) Streamingto jmpfuncs Encoding indexableas 5 Encoding indexableas 0 Finished SCC of Streaming SCC of (0x76af36a8) Finished SCC of Existing SCC of (0x76af36a8) Streaming SCC of (0x76af9a40) Streamingto jmpfuncs Encoding indexableas 0 Finished SCC of Existing SCC of (0x76af3690) Existing SCC of (0x76af3690) So as seen, the integer_cst in GOOD version points to same tree (0x76af3690), while in the bad one, there are multiple integer constants. Martin I thought there's some caching happening in IPA CP?
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #7 from Martin Liška --- And the problematic integer_cst lives in: Creating output block for jmpfuncs ... Creating compressed section
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #6 from Martin Liška --- So apparently it started with r265391, where following hunk removal fixed that: diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c index b7b0fd8f17c..45c215d78c6 100644 --- a/gcc/gimple-ssa-evrp-analyze.c +++ b/gcc/gimple-ssa-evrp-analyze.c @@ -209,10 +209,6 @@ evrp_range_analyzer::record_ranges_from_incoming_edge (basic_block bb) value_range *old_vr = get_value_range (vrs[i].first); value_range tem (old_vr->kind (), old_vr->min (), old_vr->max ()); tem.intersect (vrs[i].second); - if (tem.kind () == old_vr->kind () - && tem.min () == old_vr->min () - && tem.max () == old_vr->max ()) - continue; push_value_range (vrs[i].first, vrs[i].second); if (is_fallthru && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt)) and as mentioned on IRC, w/o -fdump-tree-all it's all fine.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #5 from Jan Hubicka --- > > Which is caused by --param ggc-min-heapsize=1 which is used by first > invocation > of the compilation. Honza, do you call ggc_collect before streaming out? So we have IL representation diverging because of gabage collection? That looks like a bug... Honza
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- So now addresses are removed, now the difference is: diff -u 1 2 --- 1 2018-10-25 10:21:14.687285804 +0200 +++ 2 2018-10-25 10:28:16.507976840 +0200 @@ -29,9 +29,6 @@ Encoding indexableas 0 Finished SCC of -Streaming SCC of -Finished SCC of - Creating compressed section Creating output block for inline Creating compressed section Which is caused by --param ggc-min-heapsize=1 which is used by first invocation of the compilation. Honza, do you call ggc_collect before streaming out?
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #3 from Jan Hubicka --- The dumps contains addresses of tree nodes streamed. I will work out how to silence them. Honza
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- The problem appeared between r261472 and r261580
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-15 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
