[Bug tree-optimization/81661] [7/8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 2 Aug 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> So do we need some predicate that will tell us if it is safe to evaluate some
> generic expression using force_gimple_operand* and bail out if it isn't
> possible?

Yes, see for example niter analysis expand_simple_operations which avoids
to turn GIMPLE into GENERIC if that might trap.  I suspect we're
looking at a similar case here, just needs to be tracked down...

> Even if gimplify_cond_expr tried harder around:
> 3865              if (gimplify_ctxp->allow_rhs_cond_expr
> 3866                  /* If either branch has side effects or could trap, it
> can't be
> 3867                     evaluated unconditionally.  */
> 3868                  && !TREE_SIDE_EFFECTS (then_)
> 3869                  && !generic_expr_could_trap_p (then_)
> 3870                  && !TREE_SIDE_EFFECTS (else_)
> 3871                  && !generic_expr_could_trap_p (else_))
> 3872                return gimplify_pure_cond_expr (expr_p, pre_p);
> 3873    
> 3874              tmp = create_tmp_var (type, "iftmp");
> and built for the case where gimplify_pure_cond_expr can't be used a SSA_NAME
> and a PHI if we're in SSA, I guess the vast majority of callers of
> force_gimple_operand* don't really expect that the sequence might need to be
> split into several basic blocks.

Yes, which is why we shouldn't really support this.

Of course the real issue is that we can't emit a non-trapping PLUS_EXPR
besides forcing unsigned arithmetic.

That said, this would be a whole lot easier to the middle-end if
we would have lowered -ftrapv operations and the actual arithmetic
were just wrapping or undefined...  which is AFAIK where we want to
go anyway.  Given we now have the overflow IFNs maybe we can try
lowering this at gimplification time?  (and clear flag_trapv
afterwards)