(1) PING**2
(2) However, as it causes for others test-suite fails,* the
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579965.html
[Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534]
is probably more important.
[* I don't see it locally as it probably uses and finds directories from
the install dir; however, others see it (hundreds of tails)
including the regression tracker at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579963.html ]
(3) Also pending is
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579903.html
[Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
(Thanks Thomas for reviewing the auxiliary loop patch :-)
Tobias
PS: Also pending is the GFC <-> CFI descriptor conversion patch, but expect
a revised patch soon. (Fixes found issues, uses aux loop function, fixes
contiguous attribute handling, len=* with assumed-size/explicit-size arrays,
...)
On 16.09.21 14:26, Tobias Burnus wrote:
Patch PING – see comment in the follow-up email of the patch email -
and in the email(s) before in that thread.
Tobias
On 07.09.21 16:33, Tobias Burnus wrote:
Now I actually tested the patch – and fixed some issues.
OK? – It does add support for 'allocated(a[i])' by treating
it as 'allocated(a)', as 'a' must be collectively allocated
("established") on all images of the team.*
'a[i]' is (probably) an allocatable, following Malcolm in
answer to my question to the J3-list as linked below.
Tobias
* Ignoring issues related to failed images. It could
also be handled by fetching 'a' from the remote
image, but I am not sure that's better in terms of
handling failed images.
PS:
On 07.09.21 10:02, Tobias Burnus wrote:
Hi Harald,
I spend yesterday about two hours with this. Now I am still
tired but understand more. I think the confusion between the
two of us is due to wording and in which directions the
thoughts then go:
Talking about coindexed, all of a[i], b[i]%c and c%d[i] are
coindexed and there are many constraints like "shall not be
a coindexed variable" – which then rejects all of those.
That's what I was thinking of.
I think your starting point is that while ('a' = allocatable)
a, b%a, c[5]%d(1)%a
are ALLOCATABLE, adding a subobject reference such as
a(:), b%a(:,:), c[5]%d(1)%a(:,:,:)
makes the variable no longer allocatable.
I think that's what you were thinking of.
We then both argued along those different lines – which caused
the confusion as we both thought we talked about the same.
While those cases are clear, the question is whether
a[i] or b%a[i]
is allocatable or not – assuming that 'a' is a scalar.
(For an array, '(:)' has to appear before the image-selector,
which in turn makes it nonallocatable.)
I tried to pinpoint the words for this in the standard – and
failed. I think I need a "how to read the Fortran standard" 101
and some long time actually reading it :-(
Malcolm has answered me – and he believes (but only offhand) that
a[i] and b%a[i]
_are_ allocatable. See (6) at
https://mailman.j3-fortran.org/pipermail/j3/2021-September/013322.html
This implies that
if ( allocated (a[i]) .and. allocated (b%a[i]) ) stop 1
is valid.
However, I do note that coarray allocatables have to be collectively
(de)allocated, therefore
allocated (a[i]) .and. allocated (b%a[i])
is equivalent to
allocated (a) .and. allocated (b%a)
at least assuming that no image has failed.
First: Does this answer all the questions you had and resolved the
confusion?
Secondly, do you agree about the last bits of the analysis?
Thirdly, what do you think of the attached patch?
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
