This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Two possible fixes for g++.dg/torture/pr32950.C failure
- From: Martin Jambor <mjambor at suse dot cz>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sun, 14 Jun 2009 04:36:35 +0200
- Subject: Re: RFC: Two possible fixes for g++.dg/torture/pr32950.C failure
- References: <200906122245.n5CMjO801391@lucas.cup.hp.com>
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