Re: ping re F2003 and F2008 standards compliance
Hi Sandra,
Some weeks ago Andrew Benson triggered me to recover a patch for
finalization in ordinary assignment. I have attached the patch and the
testcase for early review. The main change that the patch makes is to call
Tobias's finalization wrapper rather than the direct finalizer calls from
structure_alloc_comps. This ensures that finalization and deallocation
occur in the correct order for finalizable extended types with finalizable
components. I think that the chunks in resolve.c for WHERE assignment are
possibly incorrect. I will be checking the standards before submission.
We have been checking out a standards issue with the reduced testcase
'clf_demo.f90', which is also attached. A certain other brand finalizes
SOURCE in ALLOCATE (res, SOURCE = src) in the function 'constructor'. I can
find no mention of this being required in either the F2008 or F2018
standards.
Regards
Paul
On Mon, 1 Nov 2021 at 21:13, Sandra Loosemore
wrote:
> With my documentation maintainer hat on, I've been working on updating
> the standards compliance and TS29113-related material in the GNU Fortran
> manual (patches will be posted soon). I also spent some time going
> through the related wiki pages a few days ago to get them updated as well.
>
> For F2003
>
> https://gcc.gnu.org/wiki/Fortran2003Status
>
> the only thing missing before we can claim full support is some cases of
> finalization -- see comment #27 in PR37336.
>
> For F2008
>
> https://gcc.gnu.org/wiki/Fortran2008Status
>
> we are missing only PR78219 (affecting DO CONCURRENT and FORALL) and the
> "Data statement restrictions lifted" item.
>
> I think it would be a Good Thing to be able to claim full implementation
> of these standards, so is anybody interested in tackling these issues in
> the time left for GCC 12? I wouldn't mind working on one or more of
> these myself, but it looks like my management has different plans for my
> time now that the TS29113-related work is winding down. :-S
>
> -Sandra
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index af71b132dec..f8b17e29a8d 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -10490,6 +10490,10 @@ resolve_where (gfc_code *code, gfc_expr *mask)
if (e && !resolve_where_shape (cnext->expr1, e))
gfc_error ("WHERE assignment target at %L has "
"inconsistent shape", &cnext->expr1->where);
+
+ if (cnext->op == EXEC_ASSIGN)
+ cnext->expr1->must_finalize = 1;
+
break;
@@ -10577,6 +10581,10 @@ gfc_resolve_where_code_in_forall (gfc_code *code, int nvar,
/* WHERE assignment statement */
case EXEC_ASSIGN:
gfc_resolve_assign_in_forall (cnext, nvar, var_expr);
+
+ if (cnext->op == EXEC_ASSIGN)
+ cnext->expr1->must_finalize = 1;
+
break;
/* WHERE operator assignment statement */
@@ -10623,6 +10631,10 @@ gfc_resolve_forall_body (gfc_code *code, int nvar, gfc_expr **var_expr)
case EXEC_ASSIGN:
case EXEC_POINTER_ASSIGN:
gfc_resolve_assign_in_forall (c, nvar, var_expr);
+
+ if (c->op == EXEC_ASSIGN)
+ c->expr1->must_finalize = 1;
+
break;
case EXEC_ASSIGN_CALL:
@@ -12052,6 +12064,9 @@ start:
&& code->expr1->ts.u.derived->attr.defined_assign_comp)
generate_component_assignments (&code, ns);
+ if (code->op == EXEC_ASSIGN)
+ code->expr1->must_finalize = 1;
+
break;
case EXEC_LABEL_ASSIGN:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 5ceb261b698..d67b2b82ec2 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -5656,7 +5656,12 @@ gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset,
gfc_se se;
int n;
- type = TREE_TYPE (descriptor);
+ if (expr->ts.type == BT_CLASS
+ && expr3_desc != NULL_TREE
+ && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc)))
+type = TREE_TYPE (expr3_desc);
+ else
+type = TREE_TYPE (descriptor);
stride = gfc_index_one_node;
offset = gfc_index_zero_node;
@@ -8921,7 +8926,7 @@ static gfc_actual_arglist *pdt_param_list;
static tree
structure_alloc_comps (gfc_symbol * der_type, tree decl,
tree dest, int rank, int purpose, int caf_mode,
- gfc_co_subroutines_args *args)
+ gfc_co_subroutines_args *args, bool no_finalization)
{
gfc_component *c;
gfc_loopinfo loop;
@@ -9009,11 +9014,12 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
gfc_conv_array_data (dest));
dref = gfc_build_array_ref (tmp, index, NULL);
tmp = structure_alloc_comps (der_type, vref, dref, rank,
- COPY_ALLOC_COMP, caf_mode, args);
+ COPY_ALLOC_COMP, caf_mode, args,
+ no_finalization);
}
else
tmp = structure_alloc_comps (der_type, vref, NULL_TREE, rank, purpose,
- caf_mode, args);
+ caf_mode, args, no_finalization);
gfc_add_expr_to_block (&loopbody, tmp
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. Thank you, Martin
[PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
Hi,
In addition to the patches of Steve Kargl for PR 91497:
The MIN1 and MAX1 intrinsics do explicit type conversions and should
be silenced too for -Wconversion and -Wconversion-extra.
Adjust testcase to only use *4 and *8 real types, provide a second
testcase for *10 and *16 precisions.
Regtested on Linux x86_64.
Signed-off-by Manfred Schwarb
2021-11-02 Manfred Schwarb
gcc/testsuite/ChangeLog:
PR fortran/91497
* gfortran.dg/pr91497.f90: Adjust test to only use single and
double precision. Add complex intrinsics.
--- a/gcc/testsuite/gfortran.dg/pr91497.f90
+++ b/gcc/testsuite/gfortran.dg/pr91497.f90
@@ -1,4 +1,4 @@
-! { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+! { dg-do compile }
! { dg-options "-Wall" }
! Code contributed by Manfred Schwarb
! PR fortran/91497
@@ -8,120 +8,120 @@
!
program foo
- real*4 a,aa
- real*8 b,bb
- real*10 c,cc
- real*16 d
- integer*2 e,ee
- integer*4 f,ff
- integer*8 g,gg
+ real*4 a, aa
+ real*8 b, bb
+ integer*2 e, ee
+ integer*4 f, ff
+ integer*8 g, gg
+ complex(4) ww
+ complex(8) xx
PARAMETER(a=3.1415927_4)
PARAMETER(b=3.1415927_8)
- PARAMETER(c=3.1415927_10)
- PARAMETER(d=3.1415927_16)
PARAMETER(e=123_2)
PARAMETER(f=123_4)
PARAMETER(g=123_8)
- aa=REAL(b)
- aa=REAL(c)
- aa=REAL(d)
+ aa=REAL(b)! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
aa=REAL(e)
aa=REAL(f)
aa=REAL(g)
+ aa=REAL(b, kind=4) ! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
+ bb=REAL(a, kind=8)
+
aa=FLOAT(f)
- aa=FLOOR(b)
- aa=FLOOR(c)
- aa=FLOOR(d)
- aa=CEILING(b)
- aa=CEILING(c)
- aa=CEILING(d)
- !---unknown but documented type conversions:
- !!aa=FLOATI(e)
- !!aa=FLOATJ(f)
- !!aa=FLOATK(g)
- !---documentation is wrong for sngl:
- aa=SNGL(c)
- aa=SNGL(d)
- bb=REAL(c, kind=8)
- bb=REAL(d, kind=8)
- bb=DBLE(c)
- bb=DBLE(d)
bb=DFLOAT(g)
- bb=FLOOR(c)
- bb=FLOOR(d)
- bb=CEILING(c)
- bb=CEILING(d)
- cc=REAL(d, kind=10)
- cc=FLOOR(d)
- cc=CEILING(d)
-
- aa=AINT(b)
- aa=ANINT(b)
- aa=AINT(c)
- aa=ANINT(c)
- aa=AINT(d)
- aa=ANINT(d)
+ aa=SNGL(b)! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
+ aa=AINT(a)
+ bb=AINT(b)
+ aa=AINT(b, kind=4)
bb=DINT(b)
+ aa=ANINT(a)
+ bb=ANINT(b)
+ aa=ANINT(b, kind=4)
bb=DNINT(b)
-
- ee=INT(a, kind=2)
- ee=NINT(a, kind=2)
- ee=INT(b, kind=2)
- ee=NINT(b, kind=2)
- ee=INT(c, kind=2)
- ee=NINT(c, kind=2)
- ee=INT(d, kind=2)
- ee=NINT(d, kind=2)
+ !---DEC type conversions (-fdec):
+ !!aa=FLOATI(e)
+ !!aa=FLOATJ(f)
+ !!aa=FLOATK(g)
+ aa=AMAX0(f, f)
+ aa=AMIN0(f, f)
+ aa=AMAX0(g, g)
+ aa=AMIN0(g, g)
+
+ ee=INT(a)
+ ee=INT(a, kind=2)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(2)'
+ ee=INT(b, kind=2)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(2)'
ee=INT(f, kind=2)
ee=INT(g, kind=2)
+ ff=INT(b)
+ ff=INT(a, kind=4)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+ ff=INT(b, kind=4)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(4)'
+ ff=INT(f, kind=4)
+ ff=INT(g, kind=4)
+ gg=INT(a)
+ gg=INT(a, kind=8)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(8)'
+ gg=INT(b, kind=8)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(8)'
+ gg=INT(f, kind=8)
+ gg=INT(g, kind=8)
+
ee=IFIX(a)
+ ff=IFIX(a)
+ gg=IFIX(a)
ee=IDINT(b)
- ee=IDNINT(b)
- ee=INT2(a)
- ee=INT2(b)
- ee=INT2(c)
- ee=INT2(d)
+ ff=IDINT(b)
+ gg=IDINT(b)
+ ee=INT2(a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(2)'
+ ee=INT2(b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(2)'
ee=INT2(f)
ee=INT2(g)
+ gg=INT8(a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(8)'
+ gg=INT8(b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(8)'
+ gg=INT8(f)
+ gg=INT8(g)
+
+ ff=FLOOR(b)
+ ee=FLOOR(b, kind=2)
+ ff=FLOOR(b, kind=4)
+ gg=FLOOR(b, kind=8)
+ ff=CEILING(b)
+ ee=CEILING(b, kind=2)
+ ff=CEILING(b, kind=4)
+ gg=CEILING(b, kind=8)
+ ff=MAX1(a, a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+ ff=MIN1(a, a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+ gg=MAX1(b, b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(4)'
+ gg=MIN1(b, b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(4)'
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testcase to only use *4 and *8 real types, provide a second testcase for *10 and *16 precisions. Two points: We should modify existing test cases only when necessary, because modification can impede a regression test. It is better to create a new one. While we do recognize real*4 and real*8 and so on, these are non-standard extensions, and I would like to avoid to have these with new test cases. Instead of real*8, you can use real(8) or double precision. OK with these changes to the test cases. Thanks for the patch! Best regards Thomas
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
Am 02.11.21 um 14:26 schrieb Thomas Koenig: > Hi Manfred, > >> In addition to the patches of Steve Kargl for PR 91497: >> The MIN1 and MAX1 intrinsics do explicit type conversions and should >> be silenced too for -Wconversion and -Wconversion-extra. >> >> Adjust testcase to only use *4 and *8 real types, provide a second >> testcase for *10 and *16 precisions. > Two points: > > We should modify existing test cases only when necessary, because > modification can impede a regression test. It is better to create > a new one. > Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards that Steve had used it as-is. The new testcase is more consistent and more complete. Sandra got errors on targets without REAL(16) support and requested changes, so I decided to split it. So you want me to "split" it in 3 parts? - existing test as is, only for targets with REAL(16) support - additional tests incl. complex intrinsics for targets with REAL(16) support - additional tests incl. complex intrinsics for all targets, only single and double precision OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, either it warns or it does not. > While we do recognize real*4 and real*8 and so on, these are > non-standard extensions, and I would like to avoid to have these > with new test cases. > > Instead of real*8, you can use real(8) or double precision. > Well, double precision is deprecated AFAIK. > OK with these changes to the test cases. > > Thanks for the patch! > > Best regards > > Thomas
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 2:51 AM, Martin Liška wrote: On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. My understanding was that, if this conversion is indeed going to happen, it's going to be automated by scripts? I hadn't seen any discussion of it on the list for months and thought the whole idea was on hold or scrapped, since it hasn't happened yet. In any case it does not seem reasonable to freeze the current Texinfo docs for months while waiting for it to happen, especially as we are heading into the end of the release cycle and people are finishing up changes and new features they need to document. -Sandra
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 15:48, Sandra Loosemore wrote: On 11/2/21 2:51 AM, Martin Liška wrote: On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. My understanding was that, if this conversion is indeed going to happen, it's going to be automated by scripts? Exactly, but the conversion needs some manual post-processing that I've already done. I hadn't seen any discussion of it on the list for months and thought the whole idea was on hold or scrapped, since it hasn't happened yet. There was almost no response, so that's why I contacted Gerald about help. In any case it does not seem reasonable to freeze the current Texinfo docs for months while waiting for it to happen, especially as we are heading into the end of the release cycle and people are finishing up changes and new features they need to document. Sure, I can easily rebase normal changes, but you are suggesting a complete redesign/renaming. It's going to take me some time, but I'll rebase my patches. Thanks for understanding, Martin -Sandra
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)
On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote: > Would starting from Advance Toolchain 15 with the most recent glibc make > things easier for Thomas to test? The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 9:20 AM, Martin Liška wrote: On 11/2/21 15:48, Sandra Loosemore wrote: On 11/2/21 2:51 AM, Martin Liška wrote: On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. My understanding was that, if this conversion is indeed going to happen, it's going to be automated by scripts? Exactly, but the conversion needs some manual post-processing that I've already done. I hadn't seen any discussion of it on the list for months and thought the whole idea was on hold or scrapped, since it hasn't happened yet. There was almost no response, so that's why I contacted Gerald about help. I have to admit that I was buried in technical work at the time of the previous discussion (in fact, the Fortran things I am now trying to document), and didn't have time to look at the proposed changes in any detail. I have wondered, though, why it's necessary to do this change if people don't like the way Texinfo formats output, can't we fix Texinfo? Or hack it to translate the sources to something like DocBook instead, and then adopt that as our source format? I can write documentation in any markup format, but it seems to me that structured XML-based formats are a lot more amenable to scripted manipulation than either Texinfo or restructured text. If the rest of the community is set on Sphinx, I'm fine with that, but I kind of don't see the point, myself. :-S In any case it does not seem reasonable to freeze the current Texinfo docs for months while waiting for it to happen, especially as we are heading into the end of the release cycle and people are finishing up changes and new features they need to document. Sure, I can easily rebase normal changes, but you are suggesting a complete redesign/renaming. It's going to take me some time, but I'll rebase my patches. Well, what I've done is hardly a "complete" redesign/renaming of the Fortran manual -- I've barely scratched the surface on it. My main goal was just to update the bit-rotten standards conformance sections, which were unfortunately spread among multiple places in the document. I did consolidate those few sections, but I did not make any big-picture changes to the organization of the manual, and I have not even reviewed any other parts of it for accuracy or relevance. I'd been thinking about making a pass to do some copy-editing things, like making sure all chapter/section titles use consistent title case capitalization, but I will hold off on that if it's going to cause problems. -Sandra
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
On 02.11.21 15:22, Manfred Schwarb wrote: Am 02.11.21 um 14:26 schrieb Thomas Koenig: Hi Manfred, In addition to the patches of Steve Kargl for PR 91497: The MIN1 and MAX1 intrinsics do explicit type conversions and should be silenced too for -Wconversion and -Wconversion-extra. Adjust testcase to only use *4 and *8 real types, provide a second testcase for *10 and *16 precisions. Two points: We should modify existing test cases only when necessary, because modification can impede a regression test. It is better to create a new one. Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards that Steve had used it as-is. The new testcase is more consistent and more complete. Sandra got errors on targets without REAL(16) support and requested changes, so I decided to split it. So you want me to "split" it in 3 parts? - existing test as is, only for targets with REAL(16) support - additional tests incl. complex intrinsics for targets with REAL(16) support - additional tests incl. complex intrinsics for all targets, only single and double precision OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, either it warns or it does not. Anything that tests both complex and REAL(16) is fine by me. I don't think you need to test the combination of COMPLEX(16), both codepaths have been seen by that time :-) Or you can split it three ways, like you wrote above. While we do recognize real*4 and real*8 and so on, these are non-standard extensions, and I would like to avoid to have these with new test cases. Instead of real*8, you can use real(8) or double precision. Well, double precision is deprecated AFAIK. Not in Fortran 2018. Best regards Thomas
Re: [PATCH 0/5] Fortran manual updates
On Tue, Nov 2, 2021 at 8:56 AM Sandra Loosemore wrote: > > ... I will hold off on that if it's going to cause problems. > > Thanks for taking on this task, Sandra. I'm not aware of the technical issues around mark-up formatting and the transition that's happening, but I hope nothing holds up a long-needed update to the standards conformance information. Those are really important references that I've seen people rely upon in decision-making that impacts projects. Damian
Re: ping re F2003 and F2008 standards compliance
Paul, great for getting this posted! I would approve but maybe Sandra should. Regardless, thanks for getting this together. Best Regards, Jerry On 11/2/21 1:18 AM, Paul Richard Thomas via Fortran wrote: Hi Sandra, Some weeks ago Andrew Benson triggered me to recover a patch for finalization in ordinary assignment. I have attached the patch and the testcase for early review. The main change that the patch makes is to call Tobias's finalization wrapper rather than the direct finalizer calls from structure_alloc_comps. This ensures that finalization and deallocation occur in the correct order for finalizable extended types with finalizable components. I think that the chunks in resolve.c for WHERE assignment are possibly incorrect. I will be checking the standards before submission. We have been checking out a standards issue with the reduced testcase 'clf_demo.f90', which is also attached. A certain other brand finalizes SOURCE in ALLOCATE (res, SOURCE = src) in the function 'constructor'. I can find no mention of this being required in either the F2008 or F2018 standards. Regards Paul On Mon, 1 Nov 2021 at 21:13, Sandra Loosemore wrote: With my documentation maintainer hat on, I've been working on updating the standards compliance and TS29113-related material in the GNU Fortran manual (patches will be posted soon). I also spent some time going through the related wiki pages a few days ago to get them updated as well. For F2003 https://gcc.gnu.org/wiki/Fortran2003Status the only thing missing before we can claim full support is some cases of finalization -- see comment #27 in PR37336. For F2008 https://gcc.gnu.org/wiki/Fortran2008Status we are missing only PR78219 (affecting DO CONCURRENT and FORALL) and the "Data statement restrictions lifted" item. I think it would be a Good Thing to be able to claim full implementation of these standards, so is anybody interested in tackling these issues in the time left for GCC 12? I wouldn't mind working on one or more of these myself, but it looks like my management has different plans for my time now that the TS29113-related work is winding down. :-S -Sandra
Re: ping re F2003 and F2008 standards compliance
On 11/2/21 8:11 PM, Jerry D wrote: Paul, great for getting this posted! I would approve but maybe Sandra should. Ummm, I only have approval superpowers for documentation patches, and as a relative newbie to the Fortran front end I would probably struggle to come up with anything useful to say about patches to that area, aside from potential nitpicking about coding standards, misspellings in comments, and things like that. :-S Regardless, thanks for getting this together. Yes, likewise from me! -Sandra
Bug 103054 - [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name
In TS 18508, the second summy argument of co_reduce was named "operator." In the Fortran 2018 standard, the corresponding argument has the name "operation." GFortran accepts the non-standard keyword argument name "operator" and rejects the standard name "operation." % cat co_reduce.f90 implicit none logical :: co_all= .true. call co_reduce(co_all, operator=both) call co_reduce(co_all, operation=both) contains logical pure function both(lhs,rhs) logical, intent(in) :: lhs, rhs both = lhs .and. rhs end function end % gfortran -fcoarray=single co_reduce.f90 co_reduce.f90:4:40: 4 | call co_reduce(co_all, operation=both) |1 Error: Cannot find keyword named 'operation' in call to 'co_reduce' at (1) % gfortran --version GNU Fortran (Homebrew GCC 11.2.0) 11.2.0
