[Bug tree-optimization/49580] SPEC2006 GCC benchmark build failure when run with autopar

["razya at il dot ibm.com" <gcc-bugzilla at gcc dot gnu dot org>]

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