Hi Tobias,

I think I can follow now what you are thinking, and I also had some
thoughts about what you be done in principle.

I was struggling the way I did because of:

(1) Intel rejects the code in the PR.  For my previous patch,

% ifort coarray_allocated.f90 -coarray
coarray_allocated.f90(8): error #7364: The argument to the ALLOCATED intrinsic 
cannot be a coindexed object.   [A]
  print *, allocated (a[1]) ! { dg-error "shall not be coindexed" }
----------------------^
compilation aborted for coarray_allocated.f90 (code 1)


(2) F2018: 16.9.11  ALLOCATED (ARRAY) or ALLOCATED (SCALAR)

Arguments.
ARRAY   shall be an allocatable array.
SCALAR  shall be an allocatable scalar.


(3) F2018: 9.4  Scalars

9.4.3 Coindexed named objects
A coindexed-named-object is a named scalar coarray variable followed by an 
image selector.

F2018: 9.5  Arrays (or 9.4  Scalars)

F2018: 9.6 Image selectors
An image selector determines the image index for a coindexed object.


Those are the sources of information I had, and which I interpreted in
the way that even if A is an allocatable coarray (scalar or array),
when adding an image selector, like in A[N], that object would not
satisfy the requirements for the ALLOCATED intrinsic.  It also doesn't
say coarray here.

I really didn't think about the synchronization stuff here.

I also didn't read the section on the ALLOCATE statement, but in fact
there is the following (probably in line with your argument):

9.7.1.2  Execution of an ALLOCATE statement

"The coarray shall not become allocated on an image unless it is
 successfully allocated on all active images in this team."

and the following note which says:

"When an image executes an ALLOCATE statement, communication is not
 necessarily involved apart from any required for synchronization. ..."

So a dirty shortcut could be allowed if the ALLOCATED() is considered valid.

Harald

> Gesendet: Dienstag, 07. September 2021 um 16:33 Uhr
> Von: "Tobias Burnus" <tob...@codesourcery.com>
> An: "Harald Anlauf" <anl...@gmx.de>
> Cc: "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <gcc-patc...@gcc.gnu.org>
> Betreff: [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)
>
> 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
>

Reply via email to