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.bur...@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
