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

[Steve Ellcey <sje at cup dot hp dot com>]

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.

I think this change would also allow us to get rid of the macro
MEMBER_TYPE_FORCES_BLK though I would have to look at that some more,
there is one use in compute_record_mode which we would no longer need
and one use in layout_type which I think we can get rid of.

Only ia64, rs6000, and xtensa define MEMBER_TYPE_FORCES_BLK.

Should I create and test a patch to remove compute_record_mode?

Steve Ellcey
sje@cup.hp.com