Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

[Damian Rouson]

If this moves forward, I’d like to offer example code to target in Fiats (
https://go.lbl.gov/fiats).  I presented automatic parallelization results
produced by compiling with LLVM flang-new for inference at the PAW-ATM
workshop at SC24 (see https://go.lbl.gov/just-write-fortran). It would be
great to have a similar capability with gfortran.  And I would be
especially excited if Fortran 2023 reduce locality is supported. In our
training algorithm, the use of reduce locality reduces one block of code
from around 10 statements to one statement.

Damian

On Mon, Mar 10, 2025 at 04:19 Thomas Koenig  wrote:

> Dear Chenlu,
>
> Thank you for your interest!
>
> I have forwarded your e-mail to the gfortran mailing list, where
> discussion of gfortran takes place.
>
> Best regards
>
> Thomas
>
>
>  Weitergeleitete Nachricht 
> Betreff: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran
> DO CONCURRENT Auto-Parallelization
> Datum: Mon, 10 Mar 2025 15:43:52 +1100
> Von: Zhang lv via Gcc 
> Antwort an: Zhang lv 
> An: g...@gcc.gnu.org
>
> Hi here,
>
> I'm a Master of Computer Science student at the University of Melbourne.
> Previously, I worked on implementing a GCC optimization prefetching pass
> (which involved loop unrolling) for an Alpha-like computer architecture.
> I'm set to complete my research project in July and graduate soon.
>
> I'm very interested in applying for the 2025 GSoC project and discussing
> potential ideas with the community. However, I'm still unfamiliar with the
> best way to engage in these discussions and apply for the project, so this
> is my first attempt at reaching out.
>
> My primary interest is in projects related to auto-parallelization,
> particularly the Fortran *DO CONCURRENT* project. Below, I outline my
> initial understanding of the project and would appreciate any feedback from
> the community to ensure I'm on the right track:
>
> 1. The *front-end parser* processes the Fortran *DO CONCURRENT* syntax
> and converts it into a language-independent IR—*GIMPLE*.
> 2. The *middle-end* then applies tree optimizations, utilizing SSA
> passes to optimize the code for auto-parallelization.
> 3. This project will involve both *front-end* work (parser and
> parameterized command-line flags) and *middle-end* optimizations
> (optimization passes).
>
> Loop unrolling is influenced by multiple factors, such as loop nesting and
> whether iteration counts are deterministic. A significant performance gain
> comes from reducing array memory access delays, which techniques like
> prefetching can help with. Since *DO CONCURRENT* assumes iteration
> independence, we have more flexibility to unroll loops and implement
> parallelization efficiently.
>
> One of the most exciting advantages of this project is that it enables
> auto-parallelization for a broader range of code without requiring
> developers to be an OpenMP expert. *DO CONCURRENT* in Fortran is much
> easier to use, and previous auto-parallelization techniques have been quite
> limited in their applicability, as only specific loop structures could
> benefit from them.
>
> I look forward to engaging with the community and gaining insights on how
> best to contribute to this project.
>
> Best regards,
>
> Chenlu Zhang
>

Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

[Damian Rouson]

Jerry,

See
https://github.com/BerkeleyLab/fiats/blob/c256784fbd3eb28053daad657fc01c3caaf562d4/src/fiats/neural_network_s.F90#L871.
The F2023_LOCALITY macro switches on the use of reduce locality.  The
F2018_LOCALITY macro uses only locality specifiers that were in Fortran
2018.  The F2008_LOCALITY macro switches to default locality. In this code,
the biggest savings comes from reduce locality.

Damian

On Mon, Mar 10, 2025 at 10:20 Jerry D  wrote:

> On 3/10/25 4:29 AM, Damian Rouson wrote:
> > If this moves forward, I’d like to offer example code to target in Fiats
> > (https://go.lbl.gov/fiats ).  I presented
> > automatic parallelization results produced by compiling with LLVM flang-
> > new for inference at the PAW-ATM workshop at SC24 (see https://
> > go.lbl.gov/just-write-fortran ).
> > It would be great to have a similar capability with gfortran.  And I
> > would be especially excited if Fortran 2023 reduce locality is
> > supported. In our training algorithm, the use of reduce locality reduces
> > one block of code from around 10 statements to one statement.
> >
> > Damian
> >
> Damian,
>
> Can you send an example of that one block of code as an example. You may
> have already done so, I have lost track in between some other burning
> issues.
>
> Regards,
>
> Jerry
>

[patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

[Thomas Koenig]

Hello world,

the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.

Regression-tested. OK for trunk?

Best regards

Thomas

Abstract interfaces and dummy arguments are not global.

gcc/fortran/ChangeLog:

PR fortran/119078
* frontend-passes.cc (check_against_globals): Do not check
for abstract interfaces or dummy arguments.
* resolve.cc (gfc_verify_binding_labels): Adjust comment.
Do not put abstract interfaces or dummy argument into global
namespace.

gcc/testsuite/ChangeLog:

PR fortran/119078
* gfortran.dg/interface_58.f90: New test
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 20bf6e127ff..ef9c80147cc 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -5799,7 +5799,8 @@ check_against_globals (gfc_symbol *sym)
   char buf  [200];
 
   if (sym->attr.if_source != IFSRC_IFBODY || sym->attr.flavor != FL_PROCEDURE
-  || sym->attr.generic || sym->error)
+  || sym->attr.generic || sym->error || sym->attr.abstract
+  || sym->attr.dummy)
 return;
 
   if (sym->binding_label)
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index eda31ba8adc..027c99335d1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -13883,7 +13883,8 @@ gfc_verify_DTIO_procedures (gfc_symbol *sym)
 
 /* Verify that any binding labels used in a given namespace do not collide
with the names or binding labels of any global symbols.  Multiple INTERFACE
-   for the same procedure are permitted.  */
+   for the same procedure are permitted.  Abstract interfaces and dummy
+   arguments are not checked.  */
 
 static void
 gfc_verify_binding_labels (gfc_symbol *sym)
@@ -13892,7 +13893,8 @@ gfc_verify_binding_labels (gfc_symbol *sym)
   const char *module;
 
   if (!sym || !sym->attr.is_bind_c || sym->attr.is_iso_c
-  || sym->attr.flavor == FL_DERIVED || !sym->binding_label)
+  || sym->attr.flavor == FL_DERIVED || !sym->binding_label
+  || sym->attr.abstract || sym->attr.dummy)
 return;
 
   gsym = gfc_find_case_gsymbol (gfc_gsym_root, sym->binding_label);

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

[Andre Vehreschild]

Hi Steve and Jerry,

thanks for the review and the proposed changes. I have based on them, but
needed to adapt some places, because the meaning was changed. Can you please
take another look?

Jerry, where do I find this check-script? In bin/ nothing jumps out at me to be
a check-script.

Thanks,
Andre

On Thu, 6 Mar 2025 10:22:32 -0800
Jerry D  wrote:

> On 3/6/25 10:02 AM, Steve Kargl wrote:
> > Andre,
> >
> > Here's a bit of wordsmith.  I removed the abbreviation "Esp."
> > I'm not sure if there is additional markup needed; especially,
> > with the "-fcoarray=single" I inserted.
> >
> >Coarray support has been reworked to allow access to components
> >in derived types that have not been compiled with coarray support
> >enabled; especially, when the derived type is in a binary only
> >module.  This has changed the ABI and may lead to link-time errors
> >with libraries compiled with a previous GCC version and the
> >-fcoarray=single option.  If this option has been used, it is
> >recommended to recompile the libraries.  The OpenCoarrays library
> >is not affected, because it provides support backwards compatibility
> >with the older ABI.
> >
> > I'm not sure how to test the change.
> >
> > OK to commit with or without my suggested change.
> >
>
> For www-docs there is an html check script provided. You can also review
> by looking with a web browser.
>
> For texi files, if make info succeeds and review the resulting info
> files installed in the usr/share if I recall correctly.
>
> Jerry


--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4be8081974ea721301b6b60a0b5d6e2a19502a28 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Thu, 20 Feb 2025 10:47:22 +0100
Subject: [PATCH] gcc-15/changes: Document coarray changes.

ABI of coarrays has changed.  Document possible linker errors for
caf_single.
---
 htdocs/gcc-15/changes.html | 9 +
 1 file changed, 9 insertions(+)

diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index bc071501..7e5da369 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -444,6 +444,15 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
   incompatible with the module format generated by GCC 8 - 14, but GCC
   15 can for compatibility still read GCC 8 - 14 created module
   files.
+  Coarray support has been reworked to allow access to components in derived
+  types that have not been compiled with coarray support enabled;
+  especially, when the derived type is in a binary only module.  This has
+  changed the ABI and may lead to link-time errors with object files
+  generated with a previous GCC version and to be linked to the current
+  caf_single library.  If this library is to be used, then
+  it is recommended to recompile all artifacts.  The OpenCoarrays library
+  is not affected, because it provides backwards compatibility with the
+  older ABI.
 

 
--
2.48.1

Fwd: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

[Thomas Koenig]

Dear Chenlu,

Thank you for your interest!

I have forwarded your e-mail to the gfortran mailing list, where
discussion of gfortran takes place.

Best regards

Thomas


 Weitergeleitete Nachricht 
Betreff: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran 
DO CONCURRENT Auto-Parallelization

Datum: Mon, 10 Mar 2025 15:43:52 +1100
Von: Zhang lv via Gcc 
Antwort an: Zhang lv 
An: g...@gcc.gnu.org

Hi here,

I'm a Master of Computer Science student at the University of Melbourne.
Previously, I worked on implementing a GCC optimization prefetching pass
(which involved loop unrolling) for an Alpha-like computer architecture.
I'm set to complete my research project in July and graduate soon.

I'm very interested in applying for the 2025 GSoC project and discussing
potential ideas with the community. However, I'm still unfamiliar with the
best way to engage in these discussions and apply for the project, so this
is my first attempt at reaching out.

My primary interest is in projects related to auto-parallelization,
particularly the Fortran *DO CONCURRENT* project. Below, I outline my
initial understanding of the project and would appreciate any feedback from
the community to ensure I'm on the right track:

   1. The *front-end parser* processes the Fortran *DO CONCURRENT* syntax
   and converts it into a language-independent IR—*GIMPLE*.
   2. The *middle-end* then applies tree optimizations, utilizing SSA
   passes to optimize the code for auto-parallelization.
   3. This project will involve both *front-end* work (parser and
   parameterized command-line flags) and *middle-end* optimizations
   (optimization passes).

Loop unrolling is influenced by multiple factors, such as loop nesting and
whether iteration counts are deterministic. A significant performance gain
comes from reducing array memory access delays, which techniques like
prefetching can help with. Since *DO CONCURRENT* assumes iteration
independence, we have more flexibility to unroll loops and implement
parallelization efficiently.

One of the most exciting advantages of this project is that it enables
auto-parallelization for a broader range of code without requiring
developers to be an OpenMP expert. *DO CONCURRENT* in Fortran is much
easier to use, and previous auto-parallelization techniques have been quite
limited in their applicability, as only specific loop structures could
benefit from them.

I look forward to engaging with the community and gaining insights on how
best to contribute to this project.

Best regards,

Chenlu Zhang

Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

[Harald Anlauf]

Hi Thomas,

Am 10.03.25 um 21:01 schrieb Thomas Koenig:

Hello world,

the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.

Regression-tested. OK for trunk?

Best regards

 Thomas

Abstract interfaces and dummy arguments are not global.

gcc/fortran/ChangeLog:

 PR fortran/119078
 * frontend-passes.cc (check_against_globals): Do not check
 for abstract interfaces or dummy arguments.
 * resolve.cc (gfc_verify_binding_labels): Adjust comment.
 Do not put abstract interfaces or dummy argument into global
 namespace.

gcc/testsuite/ChangeLog:

 PR fortran/119078
 * gfortran.dg/interface_58.f90: New test


the patch looks basically fine but I cannot find the testcase.

Cheers,
Harald

[PATCH] Fortran: reject SAVE of a COMMON in a BLOCK construct [PR119199]

[Harald Anlauf]

Dear all,

here's a patch that fixes a 15-regression (NULL pointer dereference)
and implements a missed check of SAVE of a COMMON in a BLOCK construct.

Two separate testcases, as the respective error messages occur at
different stages in the frontend.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From 7e8f9a0d625f1c66014f71775190218b8ac51e4b Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 10 Mar 2025 22:24:27 +0100
Subject: [PATCH] Fortran: reject SAVE of a COMMON in a BLOCK construct
 [PR119199]

	PR fortran/119199

gcc/fortran/ChangeLog:

	* decl.cc (gfc_match_save): Reject SAVE statement of a COMMON block
	when in a BLOCK construct.
	* trans-common.cc (translate_common): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

	* gfortran.dg/common_30.f90: New test.
	* gfortran.dg/common_31.f90: New test.
---
 gcc/fortran/decl.cc |  9 +
 gcc/fortran/trans-common.cc |  2 +-
 gcc/testsuite/gfortran.dg/common_30.f90 | 10 ++
 gcc/testsuite/gfortran.dg/common_31.f90 | 15 +++
 4 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/common_30.f90
 create mode 100644 gcc/testsuite/gfortran.dg/common_31.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 5a46658651a..feb454ea5b3 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9795,6 +9795,15 @@ gfc_match_save (void)
   if (m == MATCH_NO)
 	goto syntax;
 
+  /* F2023:C1108: A SAVE statement in a BLOCK construct shall contain a
+	 saved-entity-list that does not specify a common-block-name.  */
+  if (gfc_current_state () == COMP_BLOCK)
+	{
+	  gfc_error ("SAVE of COMMON block %qs at %C is not allowed "
+		 "in a BLOCK construct", n);
+	  return MATCH_ERROR;
+	}
+
   c = gfc_get_common (n, 0);
   c->saved = 1;
 
diff --git a/gcc/fortran/trans-common.cc b/gcc/fortran/trans-common.cc
index 70b45174f84..2db50da20dd 100644
--- a/gcc/fortran/trans-common.cc
+++ b/gcc/fortran/trans-common.cc
@@ -1218,7 +1218,7 @@ translate_common (gfc_common_head *common, gfc_symbol *var_list)
   align = 1;
   saw_equiv = false;
 
-  if (var_list->attr.omp_allocate)
+  if (var_list && var_list->attr.omp_allocate)
 gfc_error ("Sorry, !$OMP allocate for COMMON block variable %qs at %L "
 	   "not supported", common->name, &common->where);
 
diff --git a/gcc/testsuite/gfortran.dg/common_30.f90 b/gcc/testsuite/gfortran.dg/common_30.f90
new file mode 100644
index 000..77a86348f4a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/common_30.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! PR fortran/119199
+!
+! One cannot SAVE an undefined COMMON block
+!
+! Contributed by David Binderman
+
+program main
+  save /argmnt1/ ! { dg-error "does not exist" }
+end
diff --git a/gcc/testsuite/gfortran.dg/common_31.f90 b/gcc/testsuite/gfortran.dg/common_31.f90
new file mode 100644
index 000..b60f46d7d5a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/common_31.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! PR fortran/119199 - reject SAVE of a COMMON in a BLOCK construct
+!
+! F2023:C1108: A SAVE statement in a BLOCK construct shall contain a
+!  saved-entity-list that does not specify a common-block-name.
+!
+! Contributed by David Binderman
+
+program main
+  real r
+  common /argmnt2/ r
+  block
+save /argmnt2/ ! { dg-error "not allowed in a BLOCK construct" }
+  end block
+end
-- 
2.43.0