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.