Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental

2025-02-27 Thread Peter Hill
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

2025-02-27 Thread Jerry D

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

2025-02-27 Thread Jerry D

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

2025-02-27 Thread 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?

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]

2025-02-27 Thread Andre Vehreschild
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]

2025-02-27 Thread Thomas Schwinge
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

2025-02-27 Thread Jerry D

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

2025-02-27 Thread Harald Anlauf

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

2025-02-27 Thread Harald Anlauf

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

2025-02-27 Thread Jerry D

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

2025-02-27 Thread Thomas Schwinge
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

2025-02-27 Thread Peter Hill
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*

2025-02-27 Thread Andre Vehreschild
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