http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49580
Summary: SPEC2006 GCC benchmark build failure when run with
autopar
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@il.ibm.com
CC: rakd...@gcc.gnu.org
Host: power7 linux
Target: power7 linux
Build: power7 linux
Compilation of reload1.c fails:
gcc -c -o reload1.o -DSPEC_CPU -DNDEBUG -I. -fpeel-loops -funroll-loops
-fno-tree-vectorize -fno-vect-cost-model -fdump-tree-vect-details
-ftree-parallelize-loops=8 -fdump-tree-parloops-details -O3
-falign-functions=16 -falign-loops=32 -m64 -ffast-math -O3 -mrecip=rsqrt
-fpeel-loops -funroll-loops -fno-tree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details -ftree-parallelize-loops=8
-fdump-tree-parloops-details -g reload1.c
reload1.c: In function ‘forget_old_reloads_1’:
reload1.c:4095:1: internal compiler error: in gsi_insert_seq_nodes_after, at
gimple-iterator.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
The failure happens while parallellizing, in gimple_duplicate_sese_tail():
new_rhs = fold_build2 (MINUS_EXPR, TREE_TYPE (gimple_cond_rhs (cond_stmt)),
gimple_cond_rhs (cond_stmt),
build_int_cst (TREE_TYPE (gimple_cond_rhs
(cond_stmt)), 1));
if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
{
iters_bb = gimple_bb (SSA_NAME_DEF_STMT (gimple_cond_rhs (cond_stmt)));
for (gsi1 = gsi_start_bb (iters_bb); !gsi_end_p (gsi1); gsi_next
(&gsi1))
if (gsi_stmt (gsi1) == SSA_NAME_DEF_STMT (gimple_cond_rhs
(cond_stmt)))
break;
new_rhs = force_gimple_operand_gsi (&gsi1, new_rhs, true,
NULL_TREE,false,GSI_CONTINUE_LINKING);
}
In this case, iters_bb contains the defining stmt for
gimple_cond_rhs (cond_stmt), which is a gimple_phi stmt.
Therefore, iterating the stmts of iters_bb will not find the defining stmt
and the iterator for force_gimple_operand_gsi (&gsi1, new_rhs, true,...)
will be NULL.
One solution could be to check whether the defining stmt is a gimple_phi stmt,
and handle that correctly.
However, there's one other case that is still not covered, that is if the
definition
of gimple_cond_rhs (cond_stmt) is default_def (in which case iters_bb will be
NULL causing segmentation fault)
Instead of covering these two missing cases, it seems simpler and more elegant
to insert the stmt generated by force_gimple_operand_gsi (&gsi1, new_rhs,
true..) to the loop's preheader instead of inserting ti to iters_bb (the RHS of
the cond stmt is already defined before entering the loop, therefore can be
changed at the preheader)
Please assign this bug to me.
Thank you.
