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

[Janus Weil]

2009/10/25 Janus Weil <janus@gcc.gnu.org>:
> 2009/10/25 Richard Guenther <richard.guenther@gmail.com>:
>> On Sun, Oct 25, 2009 at 10:58 PM, Janus Weil <janus@gcc.gnu.org> wrote:
>>>>> So, what to do? Are we back to
>>>>>
>>>>> 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);
>>>>>
>>>>> or is there a better option? (One alternative could be to set the
>>>>> location only for OpenMP cases, since all other things seem to work?)
>>>>
>>>> I suggest to find out which expressions miss a proper location and fix
>>>> it where they are generated.
>>>
>>> Ok. What about using the above patchlet (or something similar) as an
>>> ad-hoc solution (for the sake of getting this PR fixed), and opening a
>>> new PR for the issue of setting correct input locations (which is in
>>> no way connected to the original intention of this PR)? I promise to
>>> have a look at the location issue myself (later) ...
>>
>> It should never happen to be a STATEMENT_LIST in the above hunk
>> (at least not resulting from foldings).  Thus, can you check just retaining
>> the original SET_EXPR_LOCATION (res, input_location)?
>
> Good point. That seems to work much better. Also removing the stuff in
> trans-openmp.c seems to work, which means one can indeed remove
> 'tree_annotate_all_with_location' completely, and with it
> 'tree_annotate_one_with_location' and 'tree_should_carry_location_p'.
>
> Will do a full boostrap + regtest of the attached patch, and probably
> commit tomorrow if successful.
>
> Afterwards, I will open a PR to check what prevents the removal of the
> remaining SET_EXPR_LOCATION in trans.c.

This is now ...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827

Cheers,
Janus