Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote: > > On 2/27/25 7:38 AM, Peter Hill wrote: > > Dear all, > > > > The attached patch fixes an ICE in gfc_resolve_code when passing an > > optional array to an elemental procedure with `-pedantic` enabled. > > PR95446 added the original check, this patch fixes the case where the > > other actual argument is an array literal (or something else other > > than a variable). The ICE is present since 11.1, so this could be > > backported? > > > > Cheers, > > Peter > > > > Hi Peter, was there a PR associated with this one? > > Jerry > > --- snip --- Hi Jerry, Nope, I couldn't find one -- should I have created one first? Cheers, Peter
ping Re: [patch, doc] PR108369 GCC: Documentation of -x option
On 2/26/25 5:58 PM, Jerry D wrote: This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for trunk and backport to 14? Regards, Jerry Author: Jerry DeLisle Date: Wed Feb 26 17:26:26 2025 -0800 GCC: Documentation of -x option This change updates information about the -x option to clarify that it does not ensure standards compliance. Sparked by discussions in the following PR. PR fortran/108369 gcc/ChangeLog: * doc/invoke.texi: Add a note to clarify. Adjust some wording.
Re: [patch, doc] PR108369 GCC: Documentation of -x option
On 2/27/25 11:31 AM, Harald Anlauf wrote: Am 27.02.25 um 02:58 schrieb Jerry D: This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for trunk and backport to 14? OK for trunk. I don't think we backport documentation fixes. No prob, Commited commit cfc9f42122f41668b986126ba7e65e3dd8bf1e9e (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Wed Feb 26 17:26:26 2025 -0800 Thanks, Jerry
[Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced
Hi all, attached patch fixes user defined finalizers in derived (class) types not getting called, when the variable declared of that type was not used in the current block. The patch ensures calling the finalizer by marking the variable referenced, if it has not been. Additionally I had to patch three testcases, because their tree-dump-scans did not fit anymore. In one case a variable was not used in the two others the counts did not match any more. Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From e86c918e59b8c1b66ce837c2b4c735204c2d5510 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Thu, 27 Feb 2025 12:27:10 +0100 Subject: [PATCH] Fortran: Ensure finalizer is called for unreferenced variable [PR118730] PR fortran/118730 gcc/fortran/ChangeLog: * resolve.cc: Mark unused derived type variable with finalizers referenced to execute finalizer when leaving scope. gcc/testsuite/ChangeLog: * gfortran.dg/class_array_15.f03: Remove unused variable. * gfortran.dg/coarray_poly_7.f90: Adapt scan-tree-dump expr. * gfortran.dg/coarray_poly_8.f90: Same. * gfortran.dg/finalize_60.f90: New test. --- gcc/fortran/resolve.cc | 8 + gcc/testsuite/gfortran.dg/class_array_15.f03 | 2 +- gcc/testsuite/gfortran.dg/coarray_poly_7.f90 | 2 +- gcc/testsuite/gfortran.dg/coarray_poly_8.f90 | 2 +- gcc/testsuite/gfortran.dg/finalize_60.f90| 33 5 files changed, 44 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/finalize_60.f90 diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 6a83a7967a8..f83d122a3a2 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -17063,6 +17063,14 @@ skip_interfaces: return; } + /* Ensure that variables of derived or class type having a finalizer are + marked used even when the variable is not used anything else in the scope. + This fixes PR118730. */ + if (sym->attr.flavor == FL_VARIABLE && !sym->attr.referenced + && (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS) + && gfc_may_be_finalized (sym->ts)) +gfc_set_sym_referenced (sym); + if (sym->attr.flavor == FL_DERIVED && !resolve_fl_derived (sym)) return; diff --git a/gcc/testsuite/gfortran.dg/class_array_15.f03 b/gcc/testsuite/gfortran.dg/class_array_15.f03 index 332b39833eb..f53b2356952 100644 --- a/gcc/testsuite/gfortran.dg/class_array_15.f03 +++ b/gcc/testsuite/gfortran.dg/class_array_15.f03 @@ -100,7 +100,7 @@ subroutine pr54992 ! This test remains as the original. implicit none type (tn), target :: b class(ncBh), pointer :: bh - class(ncBh), allocatable, dimension(:) :: t + allocate(b%cBh(1),source=defaultBhC) b%cBh(1)%hostNode => b ! #1 this worked diff --git a/gcc/testsuite/gfortran.dg/coarray_poly_7.f90 b/gcc/testsuite/gfortran.dg/coarray_poly_7.f90 index d8d83aea39b..21a3054f59c 100644 --- a/gcc/testsuite/gfortran.dg/coarray_poly_7.f90 +++ b/gcc/testsuite/gfortran.dg/coarray_poly_7.f90 @@ -18,4 +18,4 @@ end ! { dg-final { scan-tree-dump-times "foo \\(struct __class_MAIN___T_1_1t & restrict x, void \\* restrict caf_token.., integer\\(kind=\[48\]\\) caf_offset..\\)" 1 "original" } } ! { dg-final { scan-tree-dump-times "bar \\(struct __class_MAIN___T_1_1t \\* restrict x, void \\* restrict caf_token.., integer\\(kind=\[48\]\\) caf_offset..\\)" 1 "original" } } ! { dg-final { scan-tree-dump-times "bar \\(0B, 0B, 0\\);" 1 "original" } } -! { dg-final { scan-tree-dump-times "foo \\(&class.., y._data.token, \\(integer\\(kind=\[48\]\\)\\) class..._data.data - \\(integer\\(kind=\[48\]\\)\\) y._data.data\\);" 1 "original" } } +! { dg-final { scan-tree-dump-times "foo \\(&class.\[0-9\]+, y._data.token, \\(integer\\(kind=\[48\]\\)\\) class.\[0-9\]+._data.data - \\(integer\\(kind=\[48\]\\)\\) y._data.data\\);" 1 "original" } } diff --git a/gcc/testsuite/gfortran.dg/coarray_poly_8.f90 b/gcc/testsuite/gfortran.dg/coarray_poly_8.f90 index abdfc0ca5f8..9ceece419ae 100644 --- a/gcc/testsuite/gfortran.dg/coarray_poly_8.f90 +++ b/gcc/testsuite/gfortran.dg/coarray_poly_8.f90 @@ -18,4 +18,4 @@ end ! { dg-final { scan-tree-dump-times "foo \\(struct __class_MAIN___T_1_1t & restrict x, void \\* restrict caf_token.., integer\\(kind=\[48\]\\) caf_offset..\\)" 1 "original" } } ! { dg-final { scan-tree-dump-times "bar \\(struct __class_MAIN___T_1_1t \\* restrict x, void \\* restrict caf_token.., integer\\(kind=\[48\]\\) caf_offset..\\)" 1 "original" } } ! { dg-final { scan-tree-dump-times "bar \\(0B, 0B, 0\\);" 1 "original" } } -! { dg-final { scan-tree-dump-times "foo \\(&class.., y._data.token, \\(integer\\(kind=\[48\]\\)\\) class..._data.data - \\(integer\\(kind=\[48\]\\)\\) y._data.data\\);" 1 "original" } } +! { dg-final { scan-tree-dump-times "foo \\(&class.\[0-9\]+, y._data.token, \\(integer\\(kind=\[48\]\\)\\) class.\[0-9\]+._data.data - \\(integer\\(kind=\[48\]\\)\\)
Re: [PUSHED] nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]
Hi Thomas, are you really telling me, that gfortran's coarray test library is compiled for offloading to GPU (or other SIMD processors)? Because that's what NVPTX is used for most, right? In my opinion that makes no sense, because coarrays in Fortran are used for SISD style accesses. Although the new style now extracts "kernels" for the access (which are tiny; and therefore should not perform on any GPU), I'd rather expect the caf_single library to be not compiled for NVPTX-offloading. Are there different opinions? Sorry, for disturbing the NVPTX build. I wasn't aware, that it was done for caf_*. Regards, Andre On Thu, 27 Feb 2025 21:53:42 +0100 Thomas Schwinge wrote: > As of recent commit 8bf0ee8d62b8a08e808344d31354ab713157e15d > "Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage > in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and > the libgfortran target library fails to build for legacy configurations where > PTX 'alloca' is not available: > > ../../../../source-gcc/libgfortran/caf/single.c: In function > ‘_gfortran_caf_transfer_between_remotes’: > ../../../../source-gcc/libgfortran/caf/single.c:675:23: sorry, unimplemented: > dynamic stack allocation not supported 675 | transfer_desc = > __builtin_alloca (desc_size); | > ^~~~ > ../../../../source-gcc/libgfortran/caf/single.c:680:20: sorry, unimplemented: > dynamic stack allocation not supported 680 | transfer_ptr = > __builtin_alloca (*opt_dst_charlen * src_size); | > ^~ make[6]: *** [Makefile:4675: > caf/single.lo] Error 1 > > With '-mfake-ptx-alloca', libgfortran again succeeds to build, and compared > to before, we've got only a small number of regressions due to nvptx 'ld' > complaining about 'unresolved symbol __GCC_nvptx__PTX_alloca_not_supported': > > [-PASS:-]{+FAIL:+} gfortran.dg/coarray/codimension_2.f90 -fcoarray=lib > -O2 -lcaf_single (test for excess errors) > > [-PASS:-]{+FAIL:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib -O2 > -lcaf_single (test for excess errors) [-PASS:-]{+UNRESOLVED:+} > gfortran.dg/coarray/event_4.f08 -fcoarray=lib -O2 -lcaf_single [-execution > test-]{+compilation failed to produce executable+} > > [-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib > -O2 -lcaf_single (test for excess errors) [-PASS:-]{+UNRESOLVED:+} > gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib -O2 -lcaf_single > [-execution test-]{+compilation failed to produce executable+} > > [-PASS:-]{+FAIL:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 > -fcoarray=lib -O2 -lcaf_single (test for excess errors) > [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 > -fcoarray=lib -O2 -lcaf_single [-execution test-]{+compilation failed to > produce executable+} > > [-PASS:-]{+FAIL:+} gfortran.dg/coarray_43.f90 -O (test for excess > errors) > > That's acceptable for such legacy PTX configurations. > > PR target/107635 > libgfortran/ > * config/t-nvptx: New. > * configure.host [nvptx] (tmake_file): Add it. > --- > libgfortran/config/t-nvptx | 2 ++ > libgfortran/configure.host | 4 > 2 files changed, 6 insertions(+) > create mode 100644 libgfortran/config/t-nvptx > > diff --git a/libgfortran/config/t-nvptx b/libgfortran/config/t-nvptx > new file mode 100644 > index 000..88bd6eee982 > --- /dev/null > +++ b/libgfortran/config/t-nvptx > @@ -0,0 +1,2 @@ > +# Re 'alloca' usage in '../caf/single.c': > +AM_CFLAGS += -mfake-ptx-alloca > diff --git a/libgfortran/configure.host b/libgfortran/configure.host > index 291188d19c2..9abd40f511a 100644 > --- a/libgfortran/configure.host > +++ b/libgfortran/configure.host > @@ -91,6 +91,10 @@ case "${target}" in > tmake_file="t-aix" > ;; > > + nvptx-*-none) > + tmake_file="$tmake_file t-nvptx" > + ;; > + >*) > ;; > -- Andre Vehreschild * Email: vehre ad gmx dot de
[PUSHED] nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]
As of recent commit 8bf0ee8d62b8a08e808344d31354ab713157e15d "Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and the libgfortran target library fails to build for legacy configurations where PTX 'alloca' is not available: ../../../../source-gcc/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’: ../../../../source-gcc/libgfortran/caf/single.c:675:23: sorry, unimplemented: dynamic stack allocation not supported 675 | transfer_desc = __builtin_alloca (desc_size); | ^~~~ ../../../../source-gcc/libgfortran/caf/single.c:680:20: sorry, unimplemented: dynamic stack allocation not supported 680 | transfer_ptr = __builtin_alloca (*opt_dst_charlen * src_size); |^~ make[6]: *** [Makefile:4675: caf/single.lo] Error 1 With '-mfake-ptx-alloca', libgfortran again succeeds to build, and compared to before, we've got only a small number of regressions due to nvptx 'ld' complaining about 'unresolved symbol __GCC_nvptx__PTX_alloca_not_supported': [-PASS:-]{+FAIL:+} gfortran.dg/coarray/codimension_2.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) [-PASS:-]{+FAIL:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib -O2 -lcaf_single (test for excess errors) [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib -O2 -lcaf_single [-execution test-]{+compilation failed to produce executable+} [-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib -O2 -lcaf_single (test for excess errors) [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib -O2 -lcaf_single [-execution test-]{+compilation failed to produce executable+} [-PASS:-]{+FAIL:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib -O2 -lcaf_single [-execution test-]{+compilation failed to produce executable+} [-PASS:-]{+FAIL:+} gfortran.dg/coarray_43.f90 -O (test for excess errors) That's acceptable for such legacy PTX configurations. PR target/107635 libgfortran/ * config/t-nvptx: New. * configure.host [nvptx] (tmake_file): Add it. --- libgfortran/config/t-nvptx | 2 ++ libgfortran/configure.host | 4 2 files changed, 6 insertions(+) create mode 100644 libgfortran/config/t-nvptx diff --git a/libgfortran/config/t-nvptx b/libgfortran/config/t-nvptx new file mode 100644 index 000..88bd6eee982 --- /dev/null +++ b/libgfortran/config/t-nvptx @@ -0,0 +1,2 @@ +# Re 'alloca' usage in '../caf/single.c': +AM_CFLAGS += -mfake-ptx-alloca diff --git a/libgfortran/configure.host b/libgfortran/configure.host index 291188d19c2..9abd40f511a 100644 --- a/libgfortran/configure.host +++ b/libgfortran/configure.host @@ -91,6 +91,10 @@ case "${target}" in tmake_file="t-aix" ;; + nvptx-*-none) + tmake_file="$tmake_file t-nvptx" + ;; + *) ;; -- 2.34.1
Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental
On 2/27/25 12:33 PM, Peter Hill wrote: On Thu, 27 Feb 2025 at 18:09, Jerry D wrote: On 2/27/25 7:38 AM, Peter Hill wrote: Dear all, The attached patch fixes an ICE in gfc_resolve_code when passing an optional array to an elemental procedure with `-pedantic` enabled. PR95446 added the original check, this patch fixes the case where the other actual argument is an array literal (or something else other than a variable). The ICE is present since 11.1, so this could be backported? Cheers, Peter Hi Peter, was there a PR associated with this one? Jerry --- snip --- Hi Jerry, Nope, I couldn't find one -- should I have created one first? Cheers, Peter Yes please with a testcase that illustrates the problem. This way we capture some hsitory,if you dont mind. Jerry
Re: [patch, doc] PR108369 GCC: Documentation of -x option
Am 27.02.25 um 02:58 schrieb Jerry D: This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for trunk and backport to 14? OK for trunk. I don't think we backport documentation fixes. Regards, Jerry Author: Jerry DeLisle Date: Wed Feb 26 17:26:26 2025 -0800 GCC: Documentation of -x option This change updates information about the -x option to clarify that it does not ensure standards compliance. Sparked by discussions in the following PR. PR fortran/108369 gcc/ChangeLog: * doc/invoke.texi: Add a note to clarify. Adjust some wording.
Re: [Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced
Hi Andre, Am 27.02.25 um 18:36 schrieb Andre Vehreschild: Hi all, attached patch fixes user defined finalizers in derived (class) types not getting called, when the variable declared of that type was not used in the current block. The patch ensures calling the finalizer by marking the variable referenced, if it has not been. Additionally I had to patch three testcases, because their tree-dump-scans did not fit anymore. In one case a variable was not used in the two others the counts did not match any more. Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? this LGTM. Thanks for the patch! Harald Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental
On 2/27/25 7:38 AM, Peter Hill wrote: Dear all, The attached patch fixes an ICE in gfc_resolve_code when passing an optional array to an elemental procedure with `-pedantic` enabled. PR95446 added the original check, this patch fixes the case where the other actual argument is an array literal (or something else other than a variable). The ICE is present since 11.1, so this could be backported? Cheers, Peter Hi Peter, was there a PR associated with this one? Jerry --- snip ---
[OG14] OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]: avoid 'error: variable ‘saved_loc2’ set but not used [-Werror=unused-but-set-variable]' (was: [Patch] O
Hi Tobias! On 2025-02-17T19:49:43+0100, Tobias Burnus wrote: > OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant > [PR115271] The OG14 "cherry-pick" of this apparently has some different code at least in one place; trunk code: > --- a/gcc/fortran/openmp.cc > +++ b/gcc/fortran/openmp.cc > @@ -6766,32 +6766,160 @@ gfc_match_omp_declare_variant (void) > + if (!p->expr && gfc_match ("omp_num_args") == MATCH_YES) > + { > + if (!have_range) > + p->u.adj_args.range_start = need_range = true; > + else > + need_range = false; > + > + locus saved_loc2 = gfc_current_locus; > + gfc_gobble_whitespace (); > + char c = gfc_peek_ascii_char (); > + if (c == '+' || c == '-') > + { > + if (gfc_match ("+ %e", &p->expr) == MATCH_YES) > + p->u.adj_args.omp_num_args_plus = true; > + else if (gfc_match ("- %e", &p->expr) == MATCH_YES) > + p->u.adj_args.omp_num_args_minus = true; > + else if (!gfc_error_check ()) > + { > + gfc_error ("expected constant integer expression " > + "at %C"); > + p->u.adj_args.error_p = true; > + return MATCH_ERROR; > + } > + p->where = gfc_get_location_range (&saved_loc, 1, > + &saved_loc, 1, > + &gfc_current_locus); > + } > + else > + { > + p->where = gfc_get_location_range (&saved_loc, 1, > + &saved_loc, 1, > + &saved_loc2); OG14 doesn't ever use 'saved_loc2', and therefore 'error: variable ‘saved_loc2’ set but not used [-Werror=unused-but-set-variable]'. Pushed to OG14 branch commit f2ab2de88082d8c52bded3725aa78610085e072c "OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]: avoid 'error: variable ‘saved_loc2’ set but not used [-Werror=unused-but-set-variable]'", see attached. Grüße Thomas >From f2ab2de88082d8c52bded3725aa78610085e072c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 23 Feb 2025 10:34:39 +0100 Subject: [PATCH] =?UTF-8?q?OpenMP/Fortran:=20extend=20'adjust=5Fargs'=20cl?= =?UTF-8?q?ause,=20fixes=20for=20it=20and=20declare=20variant=20[PR115271]?= =?UTF-8?q?:=20avoid=20'error:=20variable=20=E2=80=98saved=5Floc2=E2=80=99?= =?UTF-8?q?=20set=20but=20not=20used=20[-Werror=3Dunused-but-set-variable]?= =?UTF-8?q?'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [...]/source-gcc/gcc/fortran/openmp.cc: In function ‘match gfc_match_omp_declare_variant()’: [...]/source-gcc/gcc/fortran/openmp.cc:7127:25: error: variable ‘saved_loc2’ set but not used [-Werror=unused-but-set-variable] 7127 | locus saved_loc2 = gfc_current_locus; | ^~ Fix-up for OG14 commit e0246616020e95e74afa9d504c8848e6e905fab4 "OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]". PR fortran/115271 gcc/fortran/ * openmp.cc (gfc_match_omp_declare_variant): Remove 'locus saved_loc2'. --- gcc/fortran/openmp.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc index 16b255ec1062..421e5276d339 100644 --- a/gcc/fortran/openmp.cc +++ b/gcc/fortran/openmp.cc @@ -7124,7 +7124,6 @@ gfc_match_omp_declare_variant (void) else need_range = false; - locus saved_loc2 = gfc_current_locus; gfc_gobble_whitespace (); char c = gfc_peek_ascii_char (); if (c == '+' || c == '-') -- 2.45.2
[PATCH] Fortran: fix check for non-optional arrays passed to elemental
Dear all, The attached patch fixes an ICE in gfc_resolve_code when passing an optional array to an elemental procedure with `-pedantic` enabled. PR95446 added the original check, this patch fixes the case where the other actual argument is an array literal (or something else other than a variable). The ICE is present since 11.1, so this could be backported? Cheers, Peter gcc/fortran/Changelog * resolve.cc (resolve_elemental_actual): When checking other actual arguments to elemental procedures, don't check attributes of literals and function calls gcc/testsuite/Changelog * gfortran.dg/pr95446.f90: Expand test case to literals and function calls Signed-off-by: Peter Hill --- gcc/fortran/resolve.cc| 4 +++- gcc/testsuite/gfortran.dg/pr95446.f90 | 14 ++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 6a83a7967a8..bf602389d5b 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -2429,7 +2429,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c) for (a = arg0; a; a = a->next) if (a != arg && a->expr->rank == arg->expr->rank - && !a->expr->symtree->n.sym->attr.optional) + && (a->expr->expr_type != EXPR_VARIABLE + || (a->expr->expr_type == EXPR_VARIABLE + && !a->expr->symtree->n.sym->attr.optional))) { t = true; break; diff --git a/gcc/testsuite/gfortran.dg/pr95446.f90 b/gcc/testsuite/gfortran.dg/pr95446.f90 index 86e1019d7af..0787658813a 100644 --- a/gcc/testsuite/gfortran.dg/pr95446.f90 +++ b/gcc/testsuite/gfortran.dg/pr95446.f90 @@ -22,6 +22,20 @@ program elemental_optional end function outer + function outer_literal(o) result(l) +integer, intent(in), optional :: o(5) +integer :: l(5) + +l = inner(o, [1,2,3,4,5]) + end function outer_literal + + function outer_func(o) result(l) +integer, intent(in), optional :: o(5) +integer :: l(5) + +l = inner(o, outer()) + end function outer_func + elemental function inner(a,b) result(x) integer, intent(in), optional :: a integer, intent(in) :: b -- 2.48.1
Re: [Fortran, Patch, PR118789, v1] Fix associate to void*
Hi Thomas, thanks for the review. Committed as gcc-15-7726-g0fc1abcc46e. Thanks again, Andre On Wed, 26 Feb 2025 21:40:51 +0100 Thomas Koenig wrote: > Hi Andre, > > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > Looks good to me. > > Thanks for the patch! > > Best regards > > Thomas > -- Andre Vehreschild * Email: vehre ad gmx dot de