Re: PING**2 – Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

[Tobias Burnus <tobias@codesourcery.com>]

(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