| Message ID | 7ac2b19a-d108-a0de-8e43-b42c4583f4a5@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
| Series | 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) | expand |
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" <tobias@codesourcery.com>
> An: "Harald Anlauf" <anlauf@gmx.de>
> Cc: "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <gcc-patches@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
>
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
(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
Hi Harald, On 22.09.21 21:47, Harald Anlauf via Fortran wrote: > while still feeling somewhat unsure (given my previous comment > and the discussion), I think your patch is basically OK. > > However, your testcase has a { dg-do compile }, so it does not > really do any runtime tests. Is that intended? If so, please > add a respective comment, or adjust the testcase. I have now moved the testcase to coarray/ and turned it into 'dg-do run'. To make it a bit more interesting, I added allocate/deallocate plus some more allocate() checks. Updating the -fdump-tree-original dump scans took a small trickery as allocate/deallocate of a coarray has some extra inlined checks (is allocated? did malloc work?) with -fcoarray=single but puts the burden to the library for -fcoarray=lib. Fortunately, there is a pointless cast for 'allocatable' which made it possible to distinguish the ==/!= 0 checks. > Otherwise this LGTM. Thanks for the review! 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
Fortran: Handle allocated() with coindexed scalars [PR93834] 2021-09-07 Harald Anlauf <anlauf@gmx.de> Tobias Burnus <tobias@codesourcery.com> While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are not allocatable, it is believed that not only 'scalar' but also 'scalar[1]' is allocatable. However, coarrays are collectively established/allocated; thus, 'allocated(scalar[i])' is equivalent to 'allocated(scalar)'. [At least when assuming that 'i' does not refer to a failed image.] PR fortran/93834 gcc/fortran/ChangeLog: * trans-intrinsic.c (gfc_conv_allocated): Cleanup. Handle coindexed scalar coarrays. gcc/testsuite/ChangeLog: * gfortran.dg/coarray_allocated.f90: New test. diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 46670baae55..c9d1aace33e 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -8887,50 +8887,63 @@ caf_this_image_ref (gfc_ref *ref) static void gfc_conv_allocated (gfc_se *se, gfc_expr *expr) { - gfc_actual_arglist *arg1; gfc_se arg1se; tree tmp; - symbol_attribute caf_attr; + bool coindexed_caf_comp = false; + gfc_expr *e = expr->value.function.actual->expr; gfc_init_se (&arg1se, NULL); - arg1 = expr->value.function.actual; - - if (arg1->expr->ts.type == BT_CLASS) + if (e->ts.type == BT_CLASS) { /* Make sure that class array expressions have both a _data component reference and an array reference.... */ - if (CLASS_DATA (arg1->expr)->attr.dimension) - gfc_add_class_array_ref (arg1->expr); + if (CLASS_DATA (e)->attr.dimension) + gfc_add_class_array_ref (e); /* .... whilst scalars only need the _data component. */ else - gfc_add_data_component (arg1->expr); + gfc_add_data_component (e); } - /* When arg1 references an allocatable component in a coarray, then call + /* When 'e' references an allocatable component in a coarray, then call the caf-library function caf_is_present (). */ - if (flag_coarray == GFC_FCOARRAY_LIB && arg1->expr->expr_type == EXPR_FUNCTION - && arg1->expr->value.function.isym - && arg1->expr->value.function.isym->id == GFC_ISYM_CAF_GET) - caf_attr = gfc_caf_attr (arg1->expr->value.function.actual->expr); - else - gfc_clear_attr (&caf_attr); - if (flag_coarray == GFC_FCOARRAY_LIB && caf_attr.codimension - && !caf_this_image_ref (arg1->expr->value.function.actual->expr->ref)) - tmp = trans_caf_is_present (se, arg1->expr->value.function.actual->expr); + if (flag_coarray == GFC_FCOARRAY_LIB && e->expr_type == EXPR_FUNCTION + && e->value.function.isym + && e->value.function.isym->id == GFC_ISYM_CAF_GET) + { + e = e->value.function.actual->expr; + if (gfc_expr_attr (e).codimension) + { + /* Last partref is the coindexed coarray. As coarrays are collectively + (de)allocated, the allocation status must be the same as the one of + the local allocation. Convert to local access. */ + for (gfc_ref *ref = e->ref; ref; ref = ref->next) + if (ref->type == REF_ARRAY && ref->u.ar.codimen) + { + for (int i = ref->u.ar.dimen; + i < ref->u.ar.dimen + ref->u.ar.codimen; ++i) + ref->u.ar.dimen_type[i] = DIMEN_THIS_IMAGE; + break; + } + } + else if (!caf_this_image_ref (e->ref)) + coindexed_caf_comp = true; + } + if (coindexed_caf_comp) + tmp = trans_caf_is_present (se, e); else { - if (arg1->expr->rank == 0) + if (e->rank == 0) { /* Allocatable scalar. */ arg1se.want_pointer = 1; - gfc_conv_expr (&arg1se, arg1->expr); + gfc_conv_expr (&arg1se, e); tmp = arg1se.expr; } else { /* Allocatable array. */ arg1se.descriptor_only = 1; - gfc_conv_expr_descriptor (&arg1se, arg1->expr); + gfc_conv_expr_descriptor (&arg1se, e); tmp = gfc_conv_descriptor_data_get (arg1se.expr); } diff --git a/gcc/testsuite/gfortran.dg/coarray_allocated.f90 b/gcc/testsuite/gfortran.dg/coarray_allocated.f90 new file mode 100644 index 00000000000..dcd334b9e30 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/coarray_allocated.f90 @@ -0,0 +1,20 @@ +! { dg-do compile } +! { dg-options "-fcoarray=lib -fdump-tree-original" } +! PR fortran/93834 - ICE in trans_caf_is_present + +program p + type t + integer, allocatable :: x[:,:,:] + end type t + integer, allocatable :: a[:] + type(t) :: c + if (allocated (a)) stop 1 + if (allocated (c%x)) stop 2 + + if (allocated (a[1])) stop 4 + if (allocated (c%x[1,2,3])) stop 5 +end + +! { dg-final { scan-tree-dump-times "a.data != 0B" 2 "original" } } +! { dg-final { scan-tree-dump-times "c.x.data != 0B" 2 "original" } } +! { dg-final { scan-tree-dump-not "_gfortran_caf_get" "original" } }
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