[Patch, Fortran] PR 41714: [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE

[Janus Weil]

2009/10/25 Richard Guenther <richard.guenther@gmail.com>:
> On Sun, Oct 25, 2009 at 6:56 PM, Janus Weil <janus@gcc.gnu.org> wrote:
>>>>> It looks OK to me except:
>>>>>
>>>>>>        PR fortran/41714
>>>>>>        * trans-expr.c (gfc_build_memcpy_call): Take care of the case that the
>>>>>>        call to '__builtin_memcpy' is optimized away (replaced by a direct
>>>>>>        assignment).
>>>>>
>>>>> How the heck does that work?  It comes out as a NOP_EXPR and yet it's
>>>>> really an assignment..... Is that documented somewhere?
>>>>
>>>> That patch looks indeed dubious.  It tests for an implementation detail
>>>> (the memcpy folder returns (void *) ({ *dst = *src; dst; })).  You should
>>>> be able to unconditionally fold-convert to void_type_node as in the
>>>> original code.  Instead tree_annotate_all_with_location should be fixed.
>>>
>>> Or rather the FE should not call this function - it assumes that the code
>>> is already gimplified.
>>
>> Ok, so you mean one should instead just do the stuff which this
>> function does, but without the extra checks? Like here:
>>
>> Index: gcc/fortran/trans.c
>> ===================================================================
>> --- gcc/fortran/trans.c (Revision 153538)
>> +++ gcc/fortran/trans.c (Arbeitskopie)
>> @@ -1282,7 +1282,11 @@ gfc_trans_code (gfc_code * code)
>>       if (res != NULL_TREE && ! IS_EMPTY_STMT (res))
>>        {
>>          if (TREE_CODE (res) == STATEMENT_LIST)
>> -           tree_annotate_all_with_location (&res, input_location);
>> +           {
>> +             tree_stmt_iterator i;
>> +             for (i = tsi_start (res); !tsi_end_p (i); tsi_next (&i))
>> +               SET_EXPR_LOCATION (tsi_stmt (i), input_location);
>> +           }
>>          else
>>            SET_EXPR_LOCATION (res, input_location);
>
> No.  I think the above should just be dropped (as well as the other
> call in the Fortran frontend).  The location should have been set
> by the various stmt builders (like build_call_expr_loc in the
> memcpy case).  For the folding of memcpy case
> the folder will have distributed the locations appropriately.
>
> The middle-end function can then be removed completely (the Fortran
> FE is the only caller).  A patch to do so is pre-approved.

Alright. Regtesting the attached patch now. Thanks for your help, Richard!

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr41714_v4.diff
Type: text/x-diff
Size: 8530 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20091025/eccba57e/attachment.bin>