This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Two possible fixes for g++.dg/torture/pr32950.C failure
2009/6/14 Martin Jambor <mjambor@suse.cz>:
> 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).
We should indeed not do it unconditionally. In the testcase in question
it would result in larger IL and possibly worse debug information only.
Richard.