RFC: Two possible fixes for g++.dg/torture/pr32950.C failure

[Martin Jambor]

Hi,

On Fri, Jun 12, 2009 at 03:45:24PM -0700, Steve Ellcey wrote:
> In investigating PR middle-end/32950 and the failure of 
> g++.dg/torture/pr32950.C.  I found one simple fix and one slightly
> larger fix that we might want to consider as a cleanup change.
> 
> I would like to find out if I should investigate the second fix or not.
> 
> The problem that we are running into is that we come into
> expand_assignment with two variables each of which is a structure
> containing a single variable of type double complex.  Because of the
> optimization done by compute_record_mode, the mode for these types is
> DCmode, not BLKmode.  But the tree type is not COMPLEX, it is a STRUCT
> containing a single field of type COMPLEX.  Now the simple fix for this
> is to modify expand_assignment with a change to look at modes instead
> of types when checking for complex assignment:
> 
> 
> Index: expr.c
> ===================================================================
> --- expr.c	(revision 148407)
> +++ expr.c	(working copy)
> @@ -4250,7 +4250,7 @@ expand_assignment (tree to, tree from, b
>        /* Handle expand_expr of a complex value returning a CONCAT.  */
>        if (GET_CODE (to_rtx) == CONCAT)
>  	{
> -	  if (TREE_CODE (TREE_TYPE (from)) == COMPLEX_TYPE)
> +	  if (COMPLEX_MODE_P (DECL_MODE (from)))
>  	    {
>  	      gcc_assert (bitpos == 0);
>  	      result = store_expr (from, to_rtx, false, nontemporal);
> 
> By checking the mode instead of the tree type we fix the ICE that we
> are running into and everything works.  (I am currently testing this
> patch for regressions).
> 
> But I am wondering about the optmization done in by compute_record_mode
> which causes this situation, this function changes the mode of a
> structure from BLKmode to the mode of its field when a structure only
> has 1 field (with some exceptions).
> 
> It seems like tree-sra should be handling this now and that it might be
> time to get rid of this ad-hoc optimization done during expansion.
> 

Note that SRA can be switched off by the user (-fno-tree-sra) and does
not run by default at -O0.  Moreover, we have already had a discussion
whether SRA should do this  unconditionally and so far we were heading
towards "no" (though  Andrew Pinski said he had  some examples showing
we should).

Martin