http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49580
--- Comment #1 from razya at il dot ibm.com 2011-07-13 10:20:08 UTC --- (In reply to comment #0) > 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. Committed this fix: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00115.html gcc benchmark builds and runs successfully. Razya
