https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81889
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #5)
> I wonder why forwprop doesn't simplify bb6 by pushing the RHS of the
> assignment to _40 into the use of _40 in the conditional.
>
> I'd guess the fortran front-end's boolean types are goofy and that's getting
> in the way of forwprop doing its job. It may be impeding other bits as well.
It is because we fold (_39 < 0) != 0 to (logical(kind=1)) (_39 >> 63) and
canonicalize_cond_expr_cond doesn't recognize that form.
Index: gcc/gimple.c
===================================================================
--- gcc/gimple.c (revision 255539)
+++ gcc/gimple.c (working copy)
@@ -2148,6 +2148,17 @@ canonicalize_cond_expr_cond (tree t)
else if (TREE_CODE (t) == BIT_XOR_EXPR)
t = build2 (NE_EXPR, TREE_TYPE (t),
TREE_OPERAND (t, 0), TREE_OPERAND (t, 1));
+ /* For (bool)(x >> 63) use x < 0. */
+ else if (CONVERT_EXPR_P (t)
+ && TREE_CODE (TREE_OPERAND (t, 0)) == RSHIFT_EXPR
+ && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 1)) == INTEGER_CST
+ && ! TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (t, 0)))
+ && compare_tree_int (TREE_OPERAND (TREE_OPERAND (t, 0), 1),
+ TYPE_PRECISION
+ (TREE_TYPE (TREE_OPERAND (t, 0))) - 1) == 0)
+ t = build2 (LT_EXPR, TREE_TYPE (t),
+ TREE_OPERAND (TREE_OPERAND (t, 0), 0),
+ build_zero_cst (TREE_TYPE (TREE_OPERAND (t, 0))));
if (is_gimple_condexpr (t))
return t;
fixes that but not the warnings (didn't expect that). As suspected the array
accesses are introduced by cunroll. I'll see what to recover from there.
