Summary: | [6 Regression] FAIL: gcc.dg/tree-ssa/pr69666.c (internal compiler error) | ||
---|---|---|---|
Product: | gcc | Reporter: | Uroš Bizjak <ubizjak> |
Component: | tree-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | jakub, jamborm, jeffreyalaw |
Priority: | P1 | ||
Version: | 6.0 | ||
Target Milestone: | 6.0 | ||
Host: | Target: | alpha-linux-gnu, powerpc64le-linux-gnu | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2016-02-24 00:00:00 |
Description
Uroš Bizjak
2016-02-24 10:37:55 UTC
Also seen on powerpc64le-unknown-linux-gnu [1]. [1] https://gcc.gnu.org/ml/gcc-testresults/2016-02/msg02511.html Martin, could you please revert your PR69666 changes from the 5 branch? The number of regressions it caused on the trunk IMHO mean that it needs some time before it settles and is perhaps only then ready for backporting. Probably a released SSA name here. Yes, it is a released SSA_NAME appearing in the IL. (gdb) p debug_tree (rhs1) <ssa_name 0x7ffff0362558 nothrowdef_stmt version 4 in-free-list> (gdb) p verify_ssaname_freelists (cfun) j.c: In function ‘fun2’: j.c:16:1: internal compiler error: in verify_ssaname_freelists, at tree-ssanames.c:205 Which is this assert: /* If any name appears in both the IL and the freelists, then something horrible has happened. */ bool intersect_p = bitmap_intersect_p (names_in_il, names_in_freelists); gcc_assert (!intersect_p); The released name comes from tree-ssa: { if (access_has_children_p (racc) && !racc->grp_unscalarized_data) { if (dump_file) { fprintf (dump_file, "Removing load: "); print_gimple_stmt (dump_file, stmt, 0, 0); } generate_subtree_copies (racc->first_child, lhs, racc->offset, 0, 0, gsi, false, false, loc); gcc_assert (stmt == gsi_stmt (*gsi)); unlink_stmt_vdef (stmt); gsi_remove (gsi, true); release_defs (stmt); sra_stats.deleted++; return SRA_AM_REMOVED; } The release_defs call releases the SSA_NAME back to the manager. So we have these statements during SRA: _4 = e[d.1_3]; _5 = (int) _4; We delete the first statement, presumably because we're going to apply SRA to the RHS of that statement. That releases _4 back to the manager, leaving this IL: ;; basic block 2, loop depth 0 ;; pred: ENTRY b.0_11 = b; _12 = (unsigned char) b.0_11; MEM[(unsigned char *)&e + 16B] = _12; _13 = a; d.1_3 = d; _5 = (int) _4; d = _5; MEM[(char * {ref-all})&c] = MEM[(char * {ref-all})&e]; e ={v} {CLOBBER}; return; ;; succ: EXIT And we call sra_modify_assign on the _5 = (int) _4 statement. But that statement does not satisfy gimple_assign_single_p so sra_modify_assign does nothing. That leaves the dangling reference to _4 in the IL and we ultimately blow up in the gimple verification routines. I've never looked at tree-sra in detail before. But ISTM given the structure of sra_modify_assign that we assume that if we delete a statement like we've done here that all references are going to get fixed by subsequent calls to sra_modify_assign. sra_modify_assign punts anything that is not gimple_assign_single_p, so perhaps we're missing a similar test elsewhere in tree-sra.c. |