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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [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).


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
> <[hidden email]> 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, (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