This bug can be triggered with a crosscompiler from x86_64-linux-gnu to alpha-linux-gnu: ~/gcc-build-alpha/gcc/cc1 -O2 -fpreprocessed -quiet pr69666.c pr69666.c: In function ‘fun2’: pr69666.c:16:1: internal compiler error: Segmentation fault } ^ 0xb0cc7f crash_signal ../../git/gcc/gcc/toplev.c:335 0x839753 is_gimple_val(tree_node*) ../../git/gcc/gcc/gimple-expr.c:780 0xb4b0d8 verify_gimple_assign_unary ../../git/gcc/gcc/tree-cfg.c:3539 0xb58e94 verify_gimple_assign ../../git/gcc/gcc/tree-cfg.c:4333 0xb5b506 verify_gimple_stmt ../../git/gcc/gcc/tree-cfg.c:4590 0xb5bb5d verify_gimple_in_cfg(function*, bool) ../../git/gcc/gcc/tree-cfg.c:5052 0xa39d0e execute_function_todo ../../git/gcc/gcc/passes.c:1958 0xa3b54e execute_todo ../../git/gcc/gcc/passes.c:2010 Please submit a full bug report, Starting program: /home/uros/gcc-build-alpha/gcc/cc1 -O2 -fpreprocessed -quiet pr69666.c warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 gdb session: Program received signal SIGSEGV, Segmentation fault. 0x0000000000839753 in is_gimple_val (t=0x2aaaae7b2558) at ../../git/gcc/gcc/gimple-expr.c:780 780 if (is_gimple_variable (t) (gdb) bt #0 0x0000000000839753 in is_gimple_val (t=0x2aaaae7b2558) at ../../git/gcc/gcc/gimple-expr.c:780 #1 0x0000000000b4b0d9 in verify_gimple_assign_unary (stmt=<optimized out>) at ../../git/gcc/gcc/tree-cfg.c:3539 #2 0x0000000000b58e95 in verify_gimple_assign (stmt=0x2aaaae7b2558) at ../../git/gcc/gcc/tree-cfg.c:4333 #3 0x0000000000b5b507 in verify_gimple_stmt (stmt=0x2aaaae7b2558) at ../../git/gcc/gcc/tree-cfg.c:4590 #4 0x0000000000b5bb5e in verify_gimple_in_cfg (fn=0x2aaaae88d1f8, verify_nothrow=true) at ../../git/gcc/gcc/tree-cfg.c:5052 #5 0x0000000000a39d0f in execute_function_todo (fn=0x2aaaae88d1f8, data=<optimized out>) at ../../git/gcc/gcc/passes.c:1958 #6 0x0000000000a3b54f in execute_todo (flags=2112) at ../../git/gcc/gcc/passes.c:2010 ... (gdb) list 775 776 bool 777 is_gimple_val (tree t) 778 { 779 /* Make loads from volatiles and memory vars explicit. */ 780 if (is_gimple_variable (t) 781 && is_gimple_reg_type (TREE_TYPE (t)) 782 && !is_gimple_reg (t)) 783 return false; 784 (gdb) p debug_generic_expr (t) _4 $1 = void
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.
Another instance of leaving a released SSA_NAME in the IL causing problems later. Verified that reverting the fix for 69666 fixes this bug as well. *** This bug has been marked as a duplicate of bug 69920 ***