[PATCH, PR 40464] Intra-SRA workaround so that PR 40464 is not hit

[Martin Jambor]

Hi,

On Fri, Aug 07, 2009 at 10:48:58AM +0200, Richard Guenther wrote:
> On Fri, 7 Aug 2009, Martin Jambor wrote:
> 
> > On Thu, Aug 06, 2009 at 02:22:26PM -0700, Richard Henderson wrote:
> > > On 08/06/2009 10:54 AM, Martin Jambor wrote:
> > > >tree-complex.c does not do this by itself but through a call to
> > > >force_gimple_opernad_gsi on "REALPART_EXPR<b._M_value>" which leads
> > > >to invocation of gimplify_var_or_parm_decl on decl "b", which, being
> > > >DECL_HAS_VALUE_EXPR_P, is translated by the means of DECL_VALUE_EXPR
> > > >into the variable that is already dead.  More details are in the bug.
> > > 
> > > From the comment in front of DECL_VALUE_EXPR:
> > >   ... once this field has been set, the decl itself may not
> > >   legitimately appear in the function.
> > > 
> > > So the bug is, in fact, that it appears as an argument to the
> > > REALPART_EXPR at all.  Where does the thing come from (or fail
> > > to go away from) in the first place?
> > > 
> > 
> > The second instruction of the first BB in function multiply of
> > g++.dg/torture/pr34099.C is "b.3 = b;" since the first gimple dump.
> > The b on the RHS has a DECL_VALUE_EXPR.  That is where it comes from.
> > 
> > Thanks, I am curious where the bug will eventually be.
> 
> Btw, instrumenting GCC like the following doesnt' show anything on
> x86_64.

Thanks for the patch, it's really useful and I'd like to see it
committed at some point in the future.  It has caused over two hundred
failures on hppa in the c test suite alone.  I have opened PR 41250
about this.

The statements with DECL_VALUE_EXPR are introduced by
gimplify_parameters() in function.c, specifically by the call to:
gimplify_assign (local, parm, &stmts);

Clearly, either this statement (introduced with the tuples merge) or
the comment are wrong.  My favorite hypothesis at the moment is that
the statement should simply not be there.  

I'm now running the testsuite with the verification patch and the
statement chucked out.  So far it seems to proceed nicely but it is
slow (and unreliable, the testsuite often just hangs for me).

I'll probably try to find another callee-copy architecture for more
thorough testing and will let you know how things work out.

Thanks,

Martin




> 
> Richard.
> 
> Index: gcc/tree-cfg.c
> ===================================================================
> --- gcc/tree-cfg.c	(revision 150516)
> +++ gcc/tree-cfg.c	(working copy)
> @@ -3120,6 +3120,13 @@ verify_expr (tree *tp, int *walk_subtree
>  	  t = TREE_OPERAND (t, 0);
>  	}
>  
> +      if ((TREE_CODE (t) == VAR_DECL || TREE_CODE (t) == PARM_DECL)
> +	  && DECL_HAS_VALUE_EXPR_P (t))
> +	{
> +	  error ("variable or parameter with value-expr in IL");
> +	  return t;
> +	}
> +
>        if (!is_gimple_min_invariant (t) && !is_gimple_lvalue (t))
>  	{
>  	  error ("invalid reference prefix");
> @@ -3127,6 +3134,17 @@ verify_expr (tree *tp, int *walk_subtree
>  	}
>        *walk_subtrees = 0;
>        break;
> +
> +    case VAR_DECL:
> +    case PARM_DECL:
> +      if (DECL_HAS_VALUE_EXPR_P (t))
> +	{
> +	  error ("variable or parameter with value-expr in IL");
> +	  return t;
> +	}
> +      *walk_subtrees = 0;
> +      break;
> +
>      case PLUS_EXPR:
>      case MINUS_EXPR:
>        /* PLUS_EXPR and MINUS_EXPR don't work on pointers, they should be done using
> Index: gcc/tree-pretty-print.c
> ===================================================================
> --- gcc/tree-pretty-print.c	(revision 150516)
> +++ gcc/tree-pretty-print.c	(working copy)
> @@ -1053,6 +1053,10 @@ dump_generic_node (pretty_printer *buffe
>      case FIELD_DECL:
>      case NAMESPACE_DECL:
>        dump_decl_name (buffer, node, flags);
> +      if ((TREE_CODE (node) == VAR_DECL
> +	   || TREE_CODE (node) == PARM_DECL)
> +	  && DECL_HAS_VALUE_EXPR_P (node))
> +	pp_string (buffer, "{VAL}");
>        break;
>  
>      case RESULT_DECL: