[Bug fortran/41212] [4.5 Regression] miscompilation at -O2

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

------- Comment #10 from rguenther at suse dot de  2009-09-03 17:23 -------
Subject: Re:  [4.5 Regression] miscompilation  at  -O2

On Thu, 3 Sep 2009, matz at gcc dot gnu dot org wrote:

> ------- Comment #9 from matz at gcc dot gnu dot org  2009-09-03 17:13 -------
> Indeed. For fixing fwprop this:
> 
> --- tree-ssa-forwprop.c (Revision 151348)
> +++ tree-ssa-forwprop.c (Arbeitskopie)
> @@ -958,7 +958,7 @@ forward_propagate_addr_expr (tree name,
>        /* If the use is in a deeper loop nest, then we do not want
>          to propagate the ADDR_EXPR into the loop as that is likely
>          adding expression evaluations into the loop.  */
> -      if (gimple_bb (use_stmt)->loop_depth > stmt_loop_depth)
> +      if (0 && gimple_bb (use_stmt)->loop_depth > stmt_loop_depth)
>         {
>           all = false;
>           continue;

Ah ... something I wanted to remove since long ago.  The theory is
that less addresses are always good and will improve alias information.

For the restrict pointer case as well, if the address is
based on a decl (thus not on an indirect reference), even if we
loose the restrict qualification that way.

> or this:
> 
> --- tree-ssa-forwprop.c (Revision 151348)
> +++ tree-ssa-forwprop.c (Arbeitskopie)
> @@ -1281,7 +1281,8 @@ tree_ssa_forward_propagate_single_use_va
>                      as well, as this is valid gimple.  */
>                   || (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
>                       && TREE_CODE (rhs) == ADDR_EXPR
> -                     && POINTER_TYPE_P (TREE_TYPE (lhs))))
> +                     && POINTER_TYPE_P (TREE_TYPE (lhs))
> +                     && !TYPE_RESTRICT (TREE_TYPE (lhs))))
>                 {
>                   STRIP_NOPS (rhs);
>                   if (!stmt_references_abnormal_ssa_name (stmt)
> 
> will both fix the issue at hand.  The first will propagate to everywhere
> (with the problem mentioned in the comment, so that would need refinement),
> the second will not touch this.
> 
> Unfortunately you are right with pre-existing accesses outside the restrict
> region.

Indeed.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212