Re: [Patch] Fortran/OpenMP: Support automatic mapping allocatable components (deep mapping)

[Thomas Schwinge]

Hi Tobias!

On 2025-04-15T11:30:18+0200, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/map-alloc-comp-6.f90
> @@ -0,0 +1,308 @@
> +! NOTE: This code uses POINTER.
> +! While map(p, var%p) etc. maps the ptr/ptr comp p / var%p (incl. 
> allocatable comps),
> +! map(var) does not map var%p.
> +
> +use iso_c_binding
> +implicit none
> +type t2
> +  integer, allocatable :: x, y, z
> +end type t2
> +type t
> +  integer, pointer :: A => null()
> +  integer, pointer :: B(:) => null()
> +  type(t2), pointer :: C => null()
> +  type(t2), pointer :: D(:,:) => null()
> +end type t
> +
> +type t3
> +  type(t) :: Q
> +  type(t) :: R(5)
> +end type
> +
> +type(t) :: var, var2
> +type(t3) :: var3, var4
> +integer(c_intptr_t) :: iptr
> +
> +! --
> +! Assign + allocate
> +allocate (var%A, source=45)
> +allocate (var%B(3), source=[1,2,3])
> +allocate (var%C)
> +var%C%x = 6; var%C%y = 5; var%C%z = 4
> +allocate (var%D(2,2))
> +var%D(1,1)%x = 1
> +var%D(1,1)%y = 2
> +var%D(1,1)%z = 3
> +var%D(2,1)%x = 4
> +var%D(2,1)%y = 5
> +var%D(2,1)%z = 6
> +var%D(1,2)%x = 11
> +var%D(1,2)%y = 12
> +var%D(1,2)%z = 13
> +var%D(2,2)%x = 14
> +var%D(2,2)%y = 15
> +var%D(2,2)%z = 16
> +
> +! Assign + allocate
> +allocate (var2%A, source=145)
> +allocate (var2%B, source=[991,992,993])
> +allocate (var2%C)
> +var2%C%x = 996; var2%C%y = 995; var2%C%z = 994
> +allocate (var2%D(2,2))
> +var2%D(1,1)%x = 199
> +var2%D(1,1)%y = 299
> +var2%D(1,1)%z = 399
> +var2%D(2,1)%x = 499
> +var2%D(2,1)%y = 599
> +var2%D(2,1)%z = 699
> +var2%D(1,2)%x = 1199
> +var2%D(1,2)%y = 1299
> +var2%D(1,2)%z = 1399
> +var2%D(2,2)%x = 1499
> +var2%D(2,2)%y = 1599
> +var2%D(2,2)%z = 1699
> +
> +block
> +  integer(c_intptr_t) :: loc_a, loc_b, loc_c, loc_d, loc2_a, loc2_b, loc2_c, 
> loc2_d
> +  loc_a = loc (var%a)
> +  loc_b = loc (var%b)
> +  loc_c = loc (var%d)
> +  loc_d = loc (var%d)
> +  loc2_a = loc (var2%a)
> +  loc2_b = loc (var2%b)
> +  loc2_c = loc (var2%c)
> +  loc2_d = loc (var2%d)
> +  ! var/var2 are mapped, but the pointer components aren't
> +  !$omp target map(to: var) map(tofrom: var2)
> +if (loc_a /= loc (var%a)) stop 31
> +if (loc_b /= loc (var%b)) stop 32
> +if (loc_c /= loc (var%d)) stop 33
> +if (loc_d /= loc (var%d)) stop 34
> +if (loc2_a /= loc (var2%a)) stop 35
> +if (loc2_b /= loc (var2%b)) stop 36
> +if (loc2_c /= loc (var2%c)) stop 37
> +if (loc2_d /= loc (var2%d)) stop 38
> +  !$omp end target
> +  if (loc_a /= loc (var%a)) stop 41
> +  if (loc_b /= loc (var%b)) stop 42
> +  if (loc_c /= loc (var%d)) stop 43
> +  if (loc_d /= loc (var%d)) stop 44
> +  if (loc2_a /= loc (var2%a)) stop 45
> +  if (loc2_b /= loc (var2%b)) stop 46
> +  if (loc2_c /= loc (var2%c)) stop 47
> +  if (loc2_d /= loc (var2%d)) stop 48
> +end block
> +
> +block
> +  ! Map only (all) components, but this maps also the alloc comps
> +  !$omp target map(to: var%a, var%b, var%c, var%d) map(tofrom: var2%a, 
> var2%b, var2%c, var2%d)
> +call foo (var,var2)
> +  !$omp end target
> +end block
> +
> +if (var2%A /= 45) stop 9
> +if (any (var2%B /= [1,2,3])) stop 10
> +if (var2%C%x /= 6) stop 11
> +if (var2%C%y /= 5) stop 11
> +if (var2%C%z /= 4) stop 11
> +block
> +  integer :: tmp_x(2,2), tmp_y(2,2), tmp_z(2,2), i, j
> +  tmp_x = reshape([1, 4, 11, 14], [2,2])
> +  tmp_y = reshape([2, 5, 12, 15], [2,2])
> +  tmp_z = reshape([3, 6, 13, 16], [2,2])
> +  do j = 1, 2
> +do i = 1, 2
> +  if (var2%D(i,j)%x /= tmp_x(i,j)) stop 12
> +  if (var2%D(i,j)%y /= tmp_y(i,j)) stop 12
> +  if (var2%D(i,j)%z /= tmp_z(i,j)) stop 12
> +end do
> +  end do
> +end block
> +
> +! Extra deallocates due to PR fortran/104697
> +deallocate(var%C%x, var%C%y, var%C%z)
> +deallocate(var%D(1,1)%x, var%D(1,1)%y, var%D(1,1)%z)
> +deallocate(var%D(2,1)%x, var%D(2,1)%y, var%D(2,1)%z)
> +deallocate(var%D(1,2)%x, var%D(1,2)%y, var%D(1,2)%z)
> +deallocate(var%D(2,2)%x, var%D(2,2)%y, var%D(2,2)%z)
> +deallocate(var%A, var%B, var%C, var%D)
> +
> +deallocate(var2%C%x, var2%C%y, var2%C%z)
> +deallocate(var2%D(1,1)%x, var2%D(1,1)%y, var2%D(1,1)%z)
> +deallocate(var2%D(2,1)%x, var2%D(2,1)%y, var2%D(2,1)%z)
> +deallocate(var2%D(1,2)%x, var2%D(1,2)%y, var2%D(1,2)%z)
> +deallocate(var2%D(2,2)%x, var2%D(2,2)%y, var2%D(2,2)%z)
> +deallocate(var2%A, var2%B, var2%C, var2%D)
> +
> +! --
> +! Assign + allocate
> +allocate (var3%Q%A, source=45)
> +allocate (var3%Q%B, source=[1,2,3])
> +allocate (var3%Q%C, source=t2(6,5,4))
> +allocate (var3%Q%D(2,2))
> +var3%Q%D(1,1) = t2(1,2,3)
> +var3%Q%D(2,1) = t2(4,5,6)
> +var3%Q%D(1,2) = t2(11,12,13)
> +var3%Q%D(2,2) = t2(14,15,16)
> +
> +allocate (var3%R(2)%A, source=45)
> +allocate (var3%R(2)%B, source=[1,2,3])
> +allocate (var3%R(2)%C, source=t2(6,5,4))
> +allocate (var3%R(2)%D(2,2))
> +var3%R(2)%D(1,1) = t2(1,2,3)
> +var3%R(2)%D(2,1) = t2(4,5,6)
> +var3%R(2)%D(1,2) = t2(11,12,13)
> +var3%R(2)%D(2,2) = t2(14,15,16)
> +
> +! Assign + alloca

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

[Jerry D]

On 4/17/25 6:20 AM, Andre Vehreschild wrote:

Hi Jerry,

thanks for the review and sorry for the long delay. With publishing the team's
patches for gfortran, I also created a pull request for OpenCoarrays. There I
was asked to add some testcase with more "beef" in it. I.e. something that
really makes use of teams and not only smoke tests it. This unfortunately made
me discover some issues, that I needed to fix. The attached patch 6/5
addresses these issues. Some of them were as easy as not being able to exit out
of change team block or an end team with a label not being parsed correctly and
not generated in resulting binary. Others were more subtle, like having to
create coarray tokens for association in the change team.

The attached patch addresses all these issues and

bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?

Btw, do I still merge to master, or am I to wait for the bump to 16th master?

Regards,
Andre



Trunk is now how 16, so this answers your question.

OK for mainline.

Jerry

--- snip ---

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

[Jerry D]

On 4/18/25 8:05 AM, Jerry D wrote:

On 4/17/25 6:20 AM, Andre Vehreschild wrote:

Hi Jerry,

thanks for the review and sorry for the long delay. With publishing 
the team's
patches for gfortran, I also created a pull request for OpenCoarrays. 
There I
was asked to add some testcase with more "beef" in it. I.e. something 
that
really makes use of teams and not only smoke tests it. This 
unfortunately made

me discover some issues, that I needed to fix. The attached patch 6/5
addresses these issues. Some of them were as easy as not being able to 
exit out
of change team block or an end team with a label not being parsed 
correctly and
not generated in resulting binary. Others were more subtle, like 
having to

create coarray tokens for association in the change team.

The attached patch addresses all these issues and

bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?

Btw, do I still merge to master, or am I to wait for the bump to 16th 
master?


Regards,
Andre



Trunk is now at 16, so this answers your question.

OK for mainline.

Jerry

--- snip ---


Based on this message:

https://gcc.gnu.org/pipermail/gcc/2025-April/245945.html

I would wait a few days.

Jerry

[patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[Jerry D]

I will be committing a fix for this to the 16 mainline tonight.

I am requesting Release Manager approval to push to 15 release branch 
after full testing here.


Regards,

Jerry

See attached diff.

2025-04-18  Steven G. Kargl  

PR fortran/119836
* resolve.cc(check_pure_function, pure_subroutine): Fix checking for
an impure subprogram within a DO CONCURRENT construct.


2025-04-18  Steven G. Kargl  

PR fortran/119836
* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: Ditto.
* gfortran.dg/pr119836_3.f90: Ditto.
* gfortran.dg/pr119836_4.f90: Ditto.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ecbd50fa69..f03708efef7 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -3260,14 +3260,30 @@ static bool check_pure_function (gfc_expr *e)
  gfc_do_concurrent_flag = 0 when the check for an impure function
  occurs.  Check the stack to see if the source code has a nested
  BLOCK construct.  */
+
   for (stack = cs_base; stack; stack = stack->prev)
 {
-  if (stack->current->op == EXEC_BLOCK) saw_block = true;
+  if (!saw_block && stack->current->op == EXEC_BLOCK)
+	{
+	  saw_block = true;
+	  continue;
+	}
+
   if (saw_block && stack->current->op == EXEC_DO_CONCURRENT)
 	{
-	  gfc_error ("Reference to impure function at %L inside a "
-		 "DO CONCURRENT", &e->where);
-	  return false;
+	  bool is_pure;
+	  is_pure = (e->value.function.isym
+		 && (e->value.function.isym->pure
+			 || e->value.function.isym->elemental))
+		|| (e->value.function.esym
+			&& (e->value.function.esym->attr.pure
+			|| e->value.function.esym->attr.elemental));
+	  if (!is_pure)
+	{
+	  gfc_error ("Reference to impure function at %L inside a "
+			 "DO CONCURRENT", &e->where);
+	  return false;
+	}
 	}
 }
 
@@ -3663,16 +3679,29 @@ pure_subroutine (gfc_symbol *sym, const char *name, locus *loc)
 
   /* A BLOCK construct within a DO CONCURRENT construct leads to
  gfc_do_concurrent_flag = 0 when the check for an impure subroutine
- occurs.  Check the stack to see if the source code has a nested
- BLOCK construct.  */
+ occurs.  Walk up the stack to see if the source code has a nested
+ construct.  */
+
   for (stack = cs_base; stack; stack = stack->prev)
 {
-  if (stack->current->op == EXEC_BLOCK) saw_block = true;
+  if (stack->current->op == EXEC_BLOCK)
+	{
+	  saw_block = true;
+	  continue;
+	}
+
   if (saw_block && stack->current->op == EXEC_DO_CONCURRENT)
 	{
-	  gfc_error ("Subroutine call at %L in a DO CONCURRENT block "
-		 "is not PURE", loc);
-	  return false;
+
+	  bool is_pure = true;
+	  is_pure = sym->attr.pure || sym->attr.elemental;
+
+	  if (!is_pure)
+	{
+	  gfc_error ("Subroutine call at %L in a DO CONCURRENT block "
+			 "is not PURE", loc);
+	  return false;
+	}
 	}
 }
 
diff --git a/gcc/testsuite/gfortran.dg/do_concurrent_all_clauses.f90 b/gcc/testsuite/gfortran.dg/do_concurrent_all_clauses.f90
index 0c8a6adcabd..a7fa7c31e41 100644
--- a/gcc/testsuite/gfortran.dg/do_concurrent_all_clauses.f90
+++ b/gcc/testsuite/gfortran.dg/do_concurrent_all_clauses.f90
@@ -18,7 +18,7 @@ program do_concurrent_all_clauses
   squared = i * i
   arr(i) = temp2 + squared
   sum = sum + arr(i)
-  max_val = max(max_val, arr(i)) ! { dg-error "Reference to impure function" }
+  max_val = max(max_val, arr(i))
 end block
   end do
   print *, arr, sum, max_val
diff --git a/gcc/testsuite/gfortran.dg/pr119836_1.f90 b/gcc/testsuite/gfortran.dg/pr119836_1.f90
new file mode 100644
index 000..984e2d0a73c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr119836_1.f90
@@ -0,0 +1,18 @@
+!
+! { dg-do run }
+!
+! PR fortran/119836
+!
+program p
+   implicit none
+   integer, parameter :: n = 4
+   integer :: i
+   integer :: y(n), x(n)
+   do concurrent (i=1:n)
+  x(i) = shiftl (i,1) ! accepted
+  block
+ y(i) = shiftl (i,1)  ! wrongly rejected
+  end block
+   end do
+   if (any(x /= y)) stop 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/pr119836_2.f90 b/gcc/testsuite/gfortran.dg/pr119836_2.f90
new file mode 100644
index 000..5e2d0c9392e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr119836_2.f90
@@ -0,0 +1,21 @@
+!
+! { dg-do compile }
+!
+! PR fortran/119836
+!
+! Although intrinsic functions contained within the Fortran standard
+! are pure procedures, many of the additional intrinsic functions
+! supplied in libgfortran are impure.  RAND() is one such function.
+!
+program foo
+   implicit none
+   integer i
+   real x(4)
+   do concurrent (i=1:4)
+  x = rand() ! { dg-error "Reference to impure function" }
+  block
+ x = rand()  ! { dg-error "Reference to impure function" }
+  end block
+   end do
+   print *, x
+end program foo
diff --git a/gcc/testsuite/gfortran.dg/pr119836_3.f90 b/gcc/testsuite/gfor

Re: Fortran 15.0.1 treats "shiftl" as impure

[Paul Richard Thomas]

Hi Christopher,

I was somewhat surprised as well to find the pre-release version of
gfortran in Fedora 42.

sudo dnf install gcc14-gfortran.x86_64
 will recover gfortran-14.2.1 for you, which is then invoked with:

pault@fedora:~/prs/pr101047$ gfortran-14 --version
GNU Fortran (GCC) 14.2.1 20250210 (Red Hat 14.2.1-8)

Regards

Paul


On Thu, 17 Apr 2025 at 04:14, ZAPART CHRISTOPHER ANDREW <
chris.zap...@nao.ac.jp> wrote:

> Hi Jerry,
>
> Thank you very much. Hopefully there won't be any other issues to complain
> about.
>
> I will re-test the compilation once Fedora 42 upgrades its gcc / gfortran
> toolchain to the one containing your fixes (yes it will take *SOME*
> time). Probably in gcc/gfortran 15.1? Or maybe Intel Clear Linux will
> update their gcc/gfortran before Fedora. Anyway, thank you!
>
> Best regards,
> Chris
>
> 2025/04/17 12:06、Jerry D のメール:
>
> On 4/16/25 6:48 PM, ZAPART CHRISTOPHER ANDREW wrote:
>
> Sorry don’t have a bugzilla account yet. For completeness here is a full
> test code that also calls a pure subroutine from within a “block” located
> inside a “do concurrent” loop.
> Regards,
> Chris
> gfortran -march=native -g -Ofast -fPIC -fno-finite-math-only -funroll-
> loops -ftree-vectorize -fopenmp -o test_concurrent_fixed_array
> test_concurrent_fixed_array.f90
> test_concurrent_fixed_array.f90:
> --- snip ---
>
>
> I have confirmed that the patch provided by Steve in PR119836 does allow
> the test case mentioned here to compile and execute. (I have made no effort
> to confirm the resulting output.)
>
> Thanks,
>
> Jerry
>
>
>

Re: Fortran 15.0.1 treats "shiftl" as impure

[ZAPART CHRISTOPHER ANDREW]

Hi Jerry,

Thank you very much. Hopefully there won't be any other issues to complain 
about.

I will re-test the compilation once Fedora 42 upgrades its gcc / gfortran 
toolchain to the one containing your fixes (yes it will take SOME time). 
Probably in gcc/gfortran 15.1? Or maybe Intel Clear Linux will update their 
gcc/gfortran before Fedora. Anyway, thank you!

Best regards,
Chris

2025/04/17 12:06、Jerry D のメール:

On 4/16/25 6:48 PM, ZAPART CHRISTOPHER ANDREW wrote:
Sorry don’t have a bugzilla account yet. For completeness here is a full test 
code that also calls a pure subroutine from within a “block” located inside a 
“do concurrent” loop.
Regards,
Chris
gfortran -march=native -g -Ofast -fPIC -fno-finite-math-only -funroll- loops 
-ftree-vectorize -fopenmp -o test_concurrent_fixed_array 
test_concurrent_fixed_array.f90
test_concurrent_fixed_array.f90:
--- snip ---

I have confirmed that the patch provided by Steve in PR119836 does allow the 
test case mentioned here to compile and execute. (I have made no effort to 
confirm the resulting output.)

Thanks,

Jerry

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[Jerry D]

On 4/18/25 5:48 PM, Jerry D wrote:

I will be committing a fix for this to the 16 mainline tonight.

I am requesting Release Manager approval to push to 15 release branch 
after full testing here.


Regards,

Jerry

See attached diff.

2025-04-18  Steven G. Kargl  

PR fortran/119836
* resolve.cc(check_pure_function, pure_subroutine): Fix checking for
an impure subprogram within a DO CONCURRENT construct.


2025-04-18  Steven G. Kargl  

PR fortran/119836
* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: Ditto.
* gfortran.dg/pr119836_3.f90: Ditto.
* gfortran.dg/pr119836_4.f90: Ditto.


I have committed to 16 and the backport to 15 is ready to go pending RM 
approval.


Best Regards,

Jerry

commit 5927077029d61fdd32531530b9568cf6949fe0dd (HEAD -> gcc15)
Author: Steven G. Kargl 
Date:   Fri Apr 18 18:05:10 2025 -0700

Fortran: Fix checking for IMPURE in DO CONCURRENT.

PR fortran/119836

gcc/fortran/ChangeLog:

* resolve.cc (check_pure_function): Fix checking for
an impure subprogram within a DO CONCURRENT construct.
(pure_subroutine): Ditto.

gcc/testsuite/ChangeLog:

* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: New test.
* gfortran.dg/pr119836_3.f90: New test.
* gfortran.dg/pr119836_4.f90: New test.

(cherry picked from commit f9ea46d946887a05d7ecbca5aeeb99fd868f6e70)

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

[Jerry D]

On 4/18/25 9:13 AM, Paul Richard Thomas wrote:

Hi Andre,

On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > wrote:


Hi Jerry,

thanks for the review and sorry for the long delay. With publishing
the team's
patches for gfortran, I also created a pull request for
OpenCoarrays. There I
was asked to add some testcase with more "beef" in it. I.e.
something that
really makes use of teams and not only smoke tests it. This
unfortunately made
me discover some issues, that I needed to fix. The attached patch 6/5
addresses these issues. Some of them were as easy as not being able
to exit out
of change team block or an end team with a label not being parsed
correctly and
not generated in resulting binary. Others were more subtle, like
having to
create coarray tokens for association in the change team.

The attached patch addresses all these issues and

bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for
mainline?

Btw, do I still merge to master, or am I to wait for the bump to
16th master?

Regards,
         Andre

This all looks good to me, except for two tiny nits. It looks as if we 
are already on 16-branch :-(


I have been religiously ending ChangeLogs at column 72 since I started 
supporting gfortran. If this is still a requirement, I suggest:

line 14: s/it is/it's/
line 23: carry "are" over to the next line.

OK for mainline and, I would suggest, backporting to 15-branch asap.

Thanks for the patch

Paul



Agree, Andre OK for 16, proceed.

Jerry

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

[Paul Richard Thomas]

Hi Andre,

On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild  wrote:

> Hi Jerry,
>
> thanks for the review and sorry for the long delay. With publishing the
> team's
> patches for gfortran, I also created a pull request for OpenCoarrays.
> There I
> was asked to add some testcase with more "beef" in it. I.e. something that
> really makes use of teams and not only smoke tests it. This unfortunately
> made
> me discover some issues, that I needed to fix. The attached patch 6/5
> addresses these issues. Some of them were as easy as not being able to
> exit out
> of change team block or an end team with a label not being parsed
> correctly and
> not generated in resulting binary. Others were more subtle, like having to
> create coarray tokens for association in the change team.
>
> The attached patch addresses all these issues and
>
> bootstraps and regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Btw, do I still merge to master, or am I to wait for the bump to 16th
> master?
>
> Regards,
> Andre
>
> This all looks good to me, except for two tiny nits. It looks as if we are
already on 16-branch :-(

I have been religiously ending ChangeLogs at column 72 since I started
supporting gfortran. If this is still a requirement, I suggest:
line 14: s/it is/it's/
line 23: carry "are" over to the next line.

OK for mainline and, I would suggest, backporting to 15-branch asap.

Thanks for the patch

Paul