[Patch, Fortran] PR67125 - ALLOCATE with source-expr lbounds/ubound off by one

[Tobias Burnus]

Hi Paul,

thanks for the review; committed as Rev. 265212.

Using your check in gfc_array_allocate won't work as already early in 
gfc_trans_allocate everything is converted to a descriptor – likewise, 
checking "expr3" wouldn't work either.

I was pondering whether to check it elsewhere in gfc_trans_allocate, but 
I think it wouldn't be straight forward either and, hence, I left it as is.

After looking at the current code of the function, I decided to check 
CLASS – and decided to add those additional experiments to the test case 
– see attachment (committed as Rev. 265215).


Tobias

Paul Richard Thomas wrote:
> Hi Tobias,
>
> Your patch is OK for trunk and, I would suggest 8-branch.
>
> As a matter of curiosity, why did you not use the condition:
> if (!(expr3_desc && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc)))  ?
>
> Your solution is fine, though.
>
> Cheers
>
> Paul
>
> On Fri, 12 Oct 2018 at 12:29, Tobias Burnus
> <tobias.burnus@physik.fu-berlin.de> wrote:
>> Hello all,
>>
>> "When an ALLOCATE statement is executed for an array with no
>>   allocate-shape-spec-list, the bounds of source-expr determine
>>   the bounds of the array." (F2018, 9.7.1.2 (6))
>>
>> That seems to work fine for arrays which have an array descriptor.
>> However, as the current code shows, it fails for array constructors
>> where the lbound is zero instead of the expected one.
>>
>> It turns out (PR67125) that functions results which don't use array
>> descriptors have the same problem as do stack/static allocated
>> array variables (PR87580).
>>
>> I am not sure that my check for array descriptors is the best but
>> it seems to work and fixes the problem.
>>
>> OK for the trunk?
>> Build and regtested on x86-64-linux.
>>
>> Tobias
>
>