Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

[Richard Biener]

On Sat, Jun 7, 2025 at 3:56 PM Yuao Ma  wrote:
>
> Hi all,
>
> This patch has been updated to conditionally fold the specified math functions
> only when using MPFR version 4.2.0 or newer.
>
> To accompany this change, the test case now utilizes `__builtin_constant_p` to
> determine whether to execute the tests against the folded functions.
>
> Let me know if this patch needs further modifications!

(edom_only_function): Add acospi/asinpi/cospi/sinpi. Remove atan
because atan NEVER produce EDOM.

please split out the ATAN handling change to a separate patch.

The other changes look OK to me from an implementation perspective - I can't
say anything about correctness given I have no idea what those new functions
do.

Richard.

> Best regards,
> Yuao
>

Re: Help my confusion with march/mtune and AMD/Intel

[Richard Biener]

On Sun, Jun 22, 2025 at 10:24 PM Thompson, Matt (GSFC-610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC]  wrote:

> All,
>
>
>
> I'm currently a bit confused and I'm hoping the gfortran gurus can help.
>
>
>
> To wit, I have a code on a system with both AMD EPYC (Milan) and Intel
> Cascade Lake nodes. The code in question I build on the Milans with either
> our "Release" flags:
>
>
>
> Fortran_FLAGS = -O3 -march=znver2 -mtune=generic -funroll-loops -g
> -ffree-line-length-none
>
> -fno-range-check -Wno-missing-include-dirs -fbacktrace
> -Wno-unused-dummy-argument
>
> -ffpe-trap=zero,overflow -fbacktrace -fallow-argument-mismatch
> -fallow-invalid-boz
>
> -falign-commons -fPIC   -pthread -pthread -fopenmp
>
>
>
> or our "Aggressive" flags:
>
>
>
> Fortran_FLAGS = -O2 -march=native -ffast-math -ftree-vectorize
> -funroll-loops
>
> --param max-unroll-times=4  -mno-fma -ffree-line-length-none
> -fno-range-check
>
> -Wno-missing-include-dirs -fbacktrace -Wno-unused-dummy-argument -g
> -fbacktrace
>
> -fallow-argument-mismatch -fallow-invalid-boz -falign-commons -fPIC
> -pthread -pthread -fopenmp
>
>
>
> The thing I'm a bit flummoxed by is that in both cases, a code built on
> AMD Milan is running on Intel Cascade Lake.
>
>
> I can sort of see how "-march=znver2 -mtune=generic" could maybe be
> clamping down instructions enough to make it boring enough to run on both,
> but how is "-march=native" doing that?
>

-march=znver2 enables all ISA features Zen2 supports, -mtune=generic tunes
optimization to a blend that's good on both AMD/Intel but does not
affect the ISA being used.

When you use -march=native then you get all ISA features enabled from the
machine you compile on - this should be only used
when you run on that very same machine (or identical copies).  Or if you
know what you are doing.  I guess you've identified
the Zen2 ISA to be the common subset so I'd say the Aggressive flags should
use -march=znver2 as well.  Or possibly it was
supposed to be used only when compiling/running on the same machine type.


>
>
> Am I just very incorrect about how -march/-mtune work? Or am I just
> incredibly lucky this code seems to be portable (i.e., my code just doesn't
> get compiled with AMD-only instructions).
>

Possibly.


> (Note: even more odd, the AMD and Intel runs with Release are zero-diff as
> well. That sort of surprised me.)
>

Well, AMD and Intel are compatible, so I wouldn't expect any actual
computation data differences (if that's
what you mean).  If you are unlucky you'd get SIGILL (illegal instruction)
in case the CPU the code runs on
doesn't support an instruction used.

Richard.


> Thanks,
>
> Matt
>
>
>
>
>
>
>
>
>
> [image: signature_2578197698] 
>
> [image: Image]
>
> *Matt Thompson*
>
> *Lead Scientific Software Engineer/Supervisor*
>
> Global Modeling and Assimilation Office
>
> Science Systems and Applications, Inc.
>
> Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
>
> o: 301-614-6712
>
> matthew.thomp...@nasa.gov
>
>
>
>
>

Re: GNU Fortran Compiler

[Paul Richard Thomas]

Hello Rich,

This list is devoted to the development and maintenance of gfortran. Please
refer to the gfortran wiki https://gcc.gnu.org/wiki/GFortran for the
information that you require. Please note that most Linux distributions
offer up to date gfortran; eg. Fedora 42 has the latest release version.

Regards

Paul


On Sun, 22 Jun 2025 at 23:53, Rich Cao  wrote:

> Dear GNU Family:
>
> Could you please provide a link to download GNU Fortran Compiler for
> Fortran 90/95 on Windows platform and Linux platform?
>
> Sincerely,
> Rich Cao
>
>

Re: [PATCH] fortran: Mention user variable in SELECT TYPE temporary variable names

[Harald Anlauf]

Hi Mikael!

Am 23.06.25 um 19:51 schrieb Mikael Morin:

Le 22/06/2025 à 21:09, Harald Anlauf a écrit :

Hi Mikael!

Am 20.06.25 um 12:08 schrieb Mikael Morin:

From: Mikael Morin 

  Regression-tested on x86_64-pc-linux-gnu.
  Ok for master?

-- >8 --

The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type.  This can produce confusing dumps with code having multiple
SELECT TYPE statements, as it isn't obvious which SELECT TYPE construct
the variable relates to.  This is especially the case with nested SELECT
TYPE statements and with SELECT TYPE variables having identical types
(and thus identical names).

This change adds one additional user-provided discriminating string in
the variable names, using the value from the SELECT TYPE variable name
or last component reference name.


The idea makes a lot of sense.


It's a purely convenience change, not a correctness issue.


While this is true, one needs to check whether all buffers used
to hold the new, longer artificial symbol name are big enough.
Skimming over the patch, I have the impression that at least
the following temporaries need to be check and likely adjusted.


Thanks for the review.  Very good point indeed.

So we have a constant, GFC_MAX_SYMBOL_LEN, bounding the size of the 
symbol name that a user is permitted to choose, making it possible to 
use static buffers based on that upper limit.


But then there are internal/artificial symbols using names that are 
built around the user-provided names, thus permitted to exceed 
GFC_MAX_SYMBOL_LEN by a few units.


This is a known problem.

There was a recent discussion to increase this limit, see also pr117381.
It is not trivial to fix this (although it might be "straightforward").

So in the end, I'm not sure that the various static buffers we have all 
around are safe in the face of these artificial symbols.  And what is 
the actual true bound on symbol names.  For what's worth gfc_get_string

uses a buffer of size 3*GFC_MAX_SYMBOL_LEN + 21.

Back to the patch, I've added a truncation to the buffers which I 
haven't extended (except for one spot, see below).  At least the 
situation shouldn't be any worse than before.


Very long identifiers are fortunately sufficiently rare, but some
people tend to test the limits...

Regression-tested on x86_64-pc-linux-gnu.  I also checked the testcase 
manually with valgrind.


Good.


Ok for master?


Yes, OK for master.

Thanks for the patch!

Harald

[PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

[Harald Anlauf]

Dear all,

here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module.  One check
incorrectly referred to the original interface name, not the
renamed one.

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

Thanks,
Harald

From 69c64f3e21b9702d19a833534f2f8621845b5c98 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 23 Jun 2025 21:33:40 +0200
Subject: [PATCH] Fortran: fix checking of renamed-on-use interface name
 [PR120784]

	PR fortran/120784

gcc/fortran/ChangeLog:

	* interface.cc (gfc_match_end_interface): If a use-associated
	symbol is renamed, use the local_name for checking.

gcc/testsuite/ChangeLog:

	* gfortran.dg/interface_63.f90: New test.
---
 gcc/fortran/interface.cc   | 13 +++--
 gcc/testsuite/gfortran.dg/interface_63.f90 | 62 ++
 2 files changed, 72 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/interface_63.f90

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index b8542920ce7..cdb838d8336 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -452,11 +452,18 @@ gfc_match_end_interface (void)
 
 case INTERFACE_DTIO:
 case INTERFACE_GENERIC:
+  /* If a use-associated symbol is renamed, check the local_name.   */
+  const char *local_name = current_interface.sym->name;
+
+  if (current_interface.sym->attr.use_assoc
+	  && current_interface.sym->attr.use_rename
+	  && current_interface.sym->ns->use_stmts->rename)
+	local_name = current_interface.sym->ns->use_stmts->rename->local_name;
+
   if (type != current_interface.type
-	  || strcmp (current_interface.sym->name, name) != 0)
+	  || strcmp (local_name, name) != 0)
 	{
-	  gfc_error ("Expecting % at %C",
-		 current_interface.sym->name);
+	  gfc_error ("Expecting % at %C", local_name);
 	  m = MATCH_ERROR;
 	}
 
diff --git a/gcc/testsuite/gfortran.dg/interface_63.f90 b/gcc/testsuite/gfortran.dg/interface_63.f90
new file mode 100644
index 000..a55e8ab431b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/interface_63.f90
@@ -0,0 +1,62 @@
+! { dg-do compile }
+! PR fortran/120784 - fix checking of renamed-on-use interface name
+!
+! Contributed by Matt Thompson  
+
+module A_mod
+  implicit none
+
+  interface Get
+ procedure :: get_1
+ procedure :: get_2
+  end interface Get
+
+contains
+
+  subroutine get_1(i)
+integer :: i
+i = 5
+  end subroutine get_1
+
+  subroutine get_2(x)
+real :: x
+x = 4
+  end subroutine get_2
+end module A_mod
+
+module B_mod
+  use A_mod, only : MyGet => Get
+  implicit none
+
+  interface MyGet
+ procedure :: other_get
+  end interface MyGet
+
+contains
+
+  subroutine other_get(c)
+character(1) :: c
+c = 'a'
+  end subroutine other_get
+
+  subroutine check_get ()
+character :: c
+integer   :: i
+real  :: r
+call myget (c)
+call myget (i)
+call myget (r)
+  end subroutine check_get
+
+end module B_MOD
+
+program p
+  use b_mod, only: myget
+  implicit none
+  character :: c
+  integer   :: i
+  real  :: r
+  call myget (c)
+  call myget (i)
+  call myget (r)
+end
-- 
2.43.0

GNU Fortran Compiler

[Rich Cao]

 Dear GNU Family:

Could you please provide a link to download GNU Fortran Compiler for
Fortran 90/95 on Windows platform and Linux platform?

Sincerely,
Rich Cao

[Patch, fortran] PR106135 - Implement F2018 IMPORT statements

[Paul Richard Thomas]

Hello All,

I was mulling over the F2018 status of gfortran, when I came across the
additions to the IMPORT statement. This seemed like such a useful addition
to fortran that I set about an implementation; thinking that this would be
low hanging fruit. Parsing and checking the constraints C897-8100 turned
out to be straightforward. C8101 was already implemented for F2008 IMPORT.
C8102 required a lot more work! (Please see the patch for the constraints.)

Steve K got in touch, when he found out that we had been working in
parallel on the new IMPORT features. Thus encouraged by our exchanges, I
ground on until the patch reached its present state. I think that the
ChangeLog is clear enough, even if the patch came out a bit long winded.

Of the existing IMPORT tests, only import3.f90 needed modification by
setting -std=f2008 because of the change in the wording of the error
messages. The new test, import12.f90, is complete IMHO but I am open to
suggestions for additions. I cannot return to working on this until the
second week of July so you have plenty of time to test and comment.

Regtests fine with x86_64 on FC42. OK for mainline?

Paul
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 69acd2da981..111ebc5f845 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1723,13 +1723,17 @@ build_sym (const char *name, int elem, gfc_charlen *cl, bool cl_deferred,
   symbol_attribute attr;
   gfc_symbol *sym;
   int upper;
-  gfc_symtree *st;
+  gfc_symtree *st, *host_st = NULL;
 
   /* Symbols in a submodule are host associated from the parent module or
  submodules. Therefore, they can be overridden by declarations in the
  submodule scope. Deal with this by attaching the existing symbol to
  a new symtree and recycling the old symtree with a new symbol...  */
   st = gfc_find_symtree (gfc_current_ns->sym_root, name);
+  if (((st && st->import_only) || (gfc_current_ns->import_state == IMPORT_ALL))
+  && gfc_current_ns->parent)
+host_st = gfc_find_symtree (gfc_current_ns->parent->sym_root, name);
+
   if (st != NULL && gfc_state_stack->state == COMP_SUBMODULE
   && st->n.sym != NULL
   && st->n.sym->attr.host_assoc && st->n.sym->attr.used_in_submodule)
@@ -1742,6 +1746,20 @@ build_sym (const char *name, int elem, gfc_charlen *cl, bool cl_deferred,
   sym->refs++;
   gfc_set_sym_referenced (sym);
 }
+  /* ...Check that F2018 IMPORT, ONLY and IMPORT, ALL statements, within the
+ current scope are not violated by local redeclarations. Note that there is
+ no need to guard for std >= F2018 because import_only and IMPORT_ALL are
+ only set for these standards.  */
+  else if (host_st && host_st->n.sym
+	   && host_st->n.sym != gfc_current_ns->proc_name
+	   && !(st && st->n.sym
+		&& (st->n.sym->attr.dummy || st->n.sym->attr.result)))
+{
+  gfc_error ("F2018: C8102 %s at %L is already imported by an %s "
+		 "statement and must not be re-declared", name, var_locus,
+		 (st && st->import_only) ? "IMPORT, ONLY" : "IMPORT, ALL");
+  return false;
+}
   /* ...Otherwise generate a new symtree and new symbol.  */
   else if (gfc_get_symbol (name, NULL, &sym, var_locus))
 return false;
@@ -5100,6 +5118,54 @@ error:
 }
 
 
+/* Match the IMPORT statement.  IMPORT was added to F2003 as
+
+   R1209 import-stmt  is IMPORT [[ :: ] import-name-list ]
+
+   C1210 (R1209) The IMPORT statement is allowed only in an interface-body.
+
+   C1211 (R1209) Each import-name shall be the name of an entity in the
+		 host scoping unit.
+
+   under the description of an interface block. Under F2008, IMPORT was
+   split out of the interface block description to 12.4.3.3 and C1210
+   became
+
+   C1210 (R1209) The IMPORT statement is allowed only in an interface-body
+		 that is not a module procedure interface body.
+
+   Finally, F2018, section 8.8, has changed the IMPORT statement to
+
+   R867 import-stmt  is IMPORT [[ :: ] import-name-list ]
+		 or IMPORT, ONLY : import-name-list
+		 or IMPORT, NONE
+		 or IMPORT, ALL
+
+   C896 (R867) An IMPORT statement shall not appear in the scoping unit of
+		a main-program, external-subprogram, module, or block-data.
+
+   C897 (R867) Each import-name shall be the name of an entity in the host
+		scoping unit.
+
+   C898  If any IMPORT statement in a scoping unit has an ONLY specifier,
+	 all IMPORT statements in that scoping unit shall have an ONLY
+	 specifier.
+
+   C899  IMPORT, NONE shall not appear in the scoping unit of a submodule.
+
+   C8100 If an IMPORT, NONE or IMPORT, ALL statement appears in a scoping
+	 unit, no other IMPORT statement shall appear in that scoping unit.
+
+   C8101 Within an interface body, an entity that is accessed by host
+	 association shall be accessible by host or use association within
+	 the host scoping unit, or explicitly declared prior to the interface
+	 body.
+
+   C8102 An entity whose name appears as an import-name or which is made
+	 accessible by an IMP

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

[Jerry D]

On 6/23/25 9:43 AM, Paul Richard Thomas wrote:

Hello All,

I was mulling over the F2018 status of gfortran, when I came across the 
additions to the IMPORT statement. This seemed like such a useful 
addition to fortran that I set about an implementation; thinking that 
this would be low hanging fruit. Parsing and checking the 
constraints C897-8100 turned out to be straightforward. C8101 was 
already implemented for F2008 IMPORT. C8102 required a lot more work! 
(Please see the patch for the constraints.)


Steve K got in touch, when he found out that we had been working in 
parallel on the new IMPORT features. Thus encouraged by our exchanges, I 
ground on until the patch reached its present state. I think that the 
ChangeLog is clear enough, even if the patch came out a bit long winded.


Of the existing IMPORT tests, only import3.f90 needed modification by 
setting -std=f2008 because of the change in the wording of the error 
messages. The new test, import12.f90, is complete IMHO but I am open to 
suggestions for additions. I cannot return to working on this until the 
second week of July so you have plenty of time to test and comment.


Regtests fine with x86_64 on FC42. OK for mainline?

Paul


I do think the new test case is very thorough. I reviewed that patch for 
anything glaring and it looks good. I also tried it on some things here 
and got what I expected.


If you and Steve have been in touch I think it is OK for mainline.

Cheers,

Jerry

Re: [PATCH] fortran: Mention user variable in SELECT TYPE temporary variable names

[Mikael Morin]

Le 22/06/2025 à 21:09, Harald Anlauf a écrit :

Hi Mikael!

Am 20.06.25 um 12:08 schrieb Mikael Morin:

From: Mikael Morin 

  Regression-tested on x86_64-pc-linux-gnu.
  Ok for master?

-- >8 --

The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type.  This can produce confusing dumps with code having multiple
SELECT TYPE statements, as it isn't obvious which SELECT TYPE construct
the variable relates to.  This is especially the case with nested SELECT
TYPE statements and with SELECT TYPE variables having identical types
(and thus identical names).

This change adds one additional user-provided discriminating string in
the variable names, using the value from the SELECT TYPE variable name
or last component reference name.


The idea makes a lot of sense.


It's a purely convenience change, not a correctness issue.


While this is true, one needs to check whether all buffers used
to hold the new, longer artificial symbol name are big enough.
Skimming over the patch, I have the impression that at least
the following temporaries need to be check and likely adjusted.


Thanks for the review.  Very good point indeed.

So we have a constant, GFC_MAX_SYMBOL_LEN, bounding the size of the 
symbol name that a user is permitted to choose, making it possible to 
use static buffers based on that upper limit.


But then there are internal/artificial symbols using names that are 
built around the user-provided names, thus permitted to exceed 
GFC_MAX_SYMBOL_LEN by a few units.


So in the end, I'm not sure that the various static buffers we have all 
around are safe in the face of these artificial symbols.  And what is 
the actual true bound on symbol names.  For what's worth gfc_get_string

uses a buffer of size 3*GFC_MAX_SYMBOL_LEN + 21.

Back to the patch, I've added a truncation to the buffers which I 
haven't extended (except for one spot, see below).  At least the 
situation shouldn't be any worse than before.


Regression-tested on x86_64-pc-linux-gnu.  I also checked the testcase 
manually with valgrind.

Ok for master?
From ff3ca6ea6c1ee38fa419c3539febf1efba50b088 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Fri, 20 Jun 2025 12:08:02 +0200
Subject: [PATCH v2] fortran: Mention user variable in SELECT TYPE temporary
 variable names

The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type.  This can produce confusing dumps with code having multiple
SELECT TYPE statements, as it isn't obvious which SELECT TYPE construct
the variable relates to.  This is especially the case with nested SELECT
TYPE statements and with SELECT TYPE variables having identical types
(and thus identical names).

This change adds one additional user-provided discriminating string in
the variable names, using the value from the SELECT TYPE variable name
or last component reference name.  The additional string may be
truncated to fit in the temporary buffer.  This requires all buffers to
have matching sizes to get the same resulting name everywhere.

gcc/fortran/ChangeLog:

	* misc.cc (gfc_var_name_for_select_type_temp): New function.
	* gfortran.h (gfc_var_name_for_select_type_temp): Declare it.
	* resolve.cc (resolve_select_type): Pick a discriminating name
	from the SELECT TYPE variable reference and use it in the name
	of the temporary variable that is generated.  Truncate name to
	the buffer size.
	* match.cc (select_type_set_tmp): Likewise.  Pass the
	discriminating name...
	(select_intrinsic_set_tmp): ... to this function.  Use the
	discriminating name likewise.  Augment the buffer size to match
	that of select_type_set_tmp and resolve_select_type.

gcc/testsuite/ChangeLog:

	* gfortran.dg/select_type_51.f90: New test.
---
 gcc/fortran/gfortran.h   |  2 ++
 gcc/fortran/match.cc | 24 -
 gcc/fortran/misc.cc  | 21 +++
 gcc/fortran/resolve.cc   | 21 ++-
 gcc/testsuite/gfortran.dg/select_type_51.f90 | 37 
 5 files changed, 88 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/select_type_51.f90

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index f73b5f9c23f..6848bd1762d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3507,6 +3507,8 @@ void gfc_done_2 (void);
 
 int get_c_kind (const char *, CInteropKind_t *);
 
+const char * gfc_var_name_for_select_type_temp (gfc_expr *);
+
 const char *gfc_closest_fuzzy_match (const char *, char **);
 inline void
 vec_push (char **&optr, size_t &osz, const char *elt)
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index a99a757bede..aa0b04afd56 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -7171,9 +7171,11 @@ select_type_push (gfc_symbol *sel)
 /* Set the temporary for the current intrinsi

[committed] OpenACC: Add 'if' clause to 'acc wait' directive

[Tobias Burnus]

This simple patch adds the 'if' clause to 'acc wait'. while OpenACC 3.0
also added it to the init, shutdown and set directive this patch only
handles 'acc wait' as that's used in the ICON code.

Committed as Rev. r16-1634-g2b077252cafa50

Tobias
commit 2b077252cafa5045498a0e0c480ee6d48c136232
Author: Tobias Burnus 
Date:   Mon Jun 23 23:24:56 2025 +0200

OpenACC: Add 'if' clause to 'acc wait' directive

OpenACC 3.0 added the 'if' clause to four directives; this patch only adds
it to 'acc wait'.

gcc/c-family/ChangeLog:

* c-omp.cc (c_finish_oacc_wait): Handle if clause.

gcc/c/ChangeLog:

* c-parser.cc (OACC_WAIT_CLAUSE_MASK): Add if clause.

gcc/cp/ChangeLog:

* parser.cc (OACC_WAIT_CLAUSE_MASK): Ass if clause.

gcc/fortran/ChangeLog:

* openmp.cc (OACC_WAIT_CLAUSES): Add if clause.
* trans-openmp.cc (gfc_trans_oacc_wait_directive): Handle it.

gcc/testsuite/ChangeLog:

* c-c++-common/goacc/acc-wait-1.c: New test.
* gfortran.dg/goacc/acc-wait-1.f90: New test.
---
 gcc/c-family/c-omp.cc  |  9 -
 gcc/c/c-parser.cc  |  3 +-
 gcc/cp/parser.cc   |  3 +-
 gcc/fortran/openmp.cc  |  2 +-
 gcc/fortran/trans-openmp.cc|  4 ++
 gcc/testsuite/c-c++-common/goacc/acc-wait-1.c  | 51 ++
 gcc/testsuite/gfortran.dg/goacc/acc-wait-1.f90 | 47 
 7 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c-omp.cc b/gcc/c-family/c-omp.cc
index 13de2fe48f9..4352214df3b 100644
--- a/gcc/c-family/c-omp.cc
+++ b/gcc/c-family/c-omp.cc
@@ -52,8 +52,8 @@ c_finish_oacc_wait (location_t loc, tree parms, tree clauses)
   vec_alloc (args, nparms + 2);
   stmt = builtin_decl_explicit (BUILT_IN_GOACC_WAIT);
 
-  if (omp_find_clause (clauses, OMP_CLAUSE_ASYNC))
-t = OMP_CLAUSE_ASYNC_EXPR (clauses);
+  if ((t = omp_find_clause (clauses, OMP_CLAUSE_ASYNC)))
+t = OMP_CLAUSE_ASYNC_EXPR (t);
   else
 t = build_int_cst (integer_type_node, GOMP_ASYNC_SYNC);
 
@@ -71,6 +71,11 @@ c_finish_oacc_wait (location_t loc, tree parms, tree clauses)
 
   stmt = build_call_expr_loc_vec (loc, stmt, args);
 
+  t = omp_find_clause (clauses, OMP_CLAUSE_IF);
+  if (t)
+stmt = build3_loc (input_location, COND_EXPR, void_type_node,
+		   OMP_CLAUSE_IF_EXPR (t), stmt, NULL_TREE);
+
   vec_free (args);
 
   return stmt;
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index faa50a4fd86..0c3e3e2889c 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -22501,7 +22501,8 @@ c_parser_oacc_update (c_parser *parser)
 */
 
 #define OACC_WAIT_CLAUSE_MASK		\
-	( (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_ASYNC) )
+	( (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_ASYNC)		\
+	| (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_IF) )
 
 static tree
 c_parser_oacc_wait (location_t loc, c_parser *parser, char *p_name)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index cfebde8b118..80fd7990bbb 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -49704,7 +49704,8 @@ cp_parser_oacc_update (cp_parser *parser, cp_token *pragma_tok)
 */
 
 #define OACC_WAIT_CLAUSE_MASK	\
-	( (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_ASYNC))
+	( (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_ASYNC)	\
+	| (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_IF))
 
 static tree
 cp_parser_oacc_wait (cp_parser *parser, cp_token *pragma_tok)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index df829403c34..fe0a47a6948 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -4474,7 +4474,7 @@ error:
| OMP_CLAUSE_COPYOUT | OMP_CLAUSE_DELETE | OMP_CLAUSE_FINALIZE	  \
| OMP_CLAUSE_DETACH)
 #define OACC_WAIT_CLAUSES \
-  omp_mask (OMP_CLAUSE_ASYNC)
+  omp_mask (OMP_CLAUSE_ASYNC) | OMP_CLAUSE_IF
 #define OACC_ROUTINE_CLAUSES \
   (omp_mask (OMP_CLAUSE_GANG) | OMP_CLAUSE_WORKER | OMP_CLAUSE_VECTOR	  \
| OMP_CLAUSE_SEQ			  \
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 2a48d4af527..a2e70fca0b3 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -6048,6 +6048,10 @@ gfc_trans_oacc_wait_directive (gfc_code *code)
 args->quick_push (gfc_convert_expr_to_tree (&block, el->expr));
 
   stmt = build_call_expr_loc_vec (loc, stmt, args);
+  if (clauses->if_expr)
+stmt = build3_loc (input_location, COND_EXPR, void_type_node,
+		   gfc_convert_expr_to_tree (&block, clauses->if_expr),
+		   stmt, NULL_TREE);
   gfc_add_expr_to_block (&block, stmt);
 
   vec_free (args);
diff --git a/gcc/testsuite/c-c++-common/goacc/acc-wait-1.c b/gcc/testsuite/c-c++-common/goacc/acc-wait-1.c
new file mode 100644
index 000..bc7ff022f17
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/acc-wait-1.c
@@ -0,0 +1,51 @@
+// { dg-do compile }
+// { dg-additional-opt

[Patch] Fortran/OpenACC: Add Fortran support for acc_attach/acc_detach

[Tobias Burnus]

This patch adds the OpenACC routines acc_attach and acc_detach.

However, in order to avoid the generation of a temporary, which
breaks this feature, a special case had to be added to
gfc_trans_call.

Otherwise, I think it completes the Fortran additions of existing
C/C++ functions, by adding this OpenACC 3.3 feature, which is used
by ICON.

Any comments, suggestions, remarks before I commit this patch?

Tobias
Fortran/OpenACC: Add Fortran support for acc_attach/acc_detach

While C/++ support the routines acc_attach{,_async} and
acc_detach{,_finalize}{,_async} routines since a long time, the Fortran
API routines where only added in OpenACC 3.3.

Unfortunately, they cannot directly be implemented in the library as
GCC will introduce a temporary array descriptor in some cases, which
causes the attempted attachment to the this temporary variable instead
of to the original one.

Therefore, those API routines are handled in a special way in the compiler.

gcc/fortran/ChangeLog:

	* trans-stmt.cc (gfc_trans_call_acc_attach_detach): New.
	(gfc_trans_call): Call it.

libgomp/ChangeLog:

	* libgomp.texi (acc_attach, acc_detach): Update for Fortran
	version.
	* openacc.f90 acc_attach{,_async}, acc_detach{,_finalize}{,_async}:
	Add.
	* openacc_lib.h: Likewise.
	* testsuite/libgomp.oacc-fortran/acc-attach-detach-1.f90: New test.
	* testsuite/libgomp.oacc-fortran/acc-attach-detach-2.f90: New test.

 gcc/fortran/trans-stmt.cc  | 74 +-
 libgomp/libgomp.texi   | 40 ++--
 libgomp/openacc.f90| 44 +
 libgomp/openacc_lib.h  | 42 
 .../libgomp.oacc-fortran/acc-attach-detach-1.f90   | 25 
 .../libgomp.oacc-fortran/acc-attach-detach-2.f90   | 62 ++
 6 files changed, 265 insertions(+), 22 deletions(-)

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 487b7687ef1..f1054015862 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -377,6 +377,57 @@ get_intrinsic_for_code (gfc_code *code)
 }
 
 
+/* Handle the OpenACC routines acc_attach{,_async} and
+   acc_detach{,_finalize}{,_async} explicitly.  This is required as the
+   the corresponding device pointee is attached to the corresponding device
+   pointer, but if a temporary array descriptor is created for the call,
+   that one is used as pointer instead of the original pointer.  */
+
+tree
+gfc_trans_call_acc_attach_detach (gfc_code *code)
+{
+  stmtblock_t block;
+  gfc_se ptr_addr_se, async_se;
+  tree fn;
+
+  fn = code->resolved_sym->backend_decl;
+  if (fn == NULL)
+{
+  fn = gfc_get_symbol_decl (code->resolved_sym);
+  code->resolved_sym->backend_decl = fn;
+}
+
+  gfc_start_block (&block);
+
+  gfc_init_se (&ptr_addr_se, NULL);
+  ptr_addr_se.descriptor_only = 1;
+  ptr_addr_se.want_pointer = 1;
+  gfc_conv_expr (&ptr_addr_se, code->ext.actual->expr);
+  gfc_add_block_to_block (&block, &ptr_addr_se.pre);
+  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (ptr_addr_se.expr)))
+ptr_addr_se.expr = gfc_conv_descriptor_data_get (ptr_addr_se.expr);
+  ptr_addr_se.expr = build_fold_addr_expr (ptr_addr_se.expr);
+
+  bool async = code->ext.actual->next != NULL;
+  if (async)
+{
+  gfc_init_se (&async_se, NULL);
+  gfc_conv_expr (&async_se, code->ext.actual->next->expr);
+  fn = build_call_expr_loc (gfc_get_location (&code->loc), fn, 2,
+ptr_addr_se.expr, async_se.expr);
+}
+  else
+fn = build_call_expr_loc (gfc_get_location (&code->loc),
+			  fn, 1, ptr_addr_se.expr);
+  gfc_add_expr_to_block (&block, fn);
+  gfc_add_block_to_block (&block, &ptr_addr_se.post);
+  if (async)
+gfc_add_block_to_block (&block, &async_se.post);
+
+  return gfc_finish_block (&block);
+}
+
+
 /* Translate the CALL statement.  Builds a call to an F95 subroutine.  */
 
 tree
@@ -392,13 +443,32 @@ gfc_trans_call (gfc_code * code, bool dependency_check,
   tree tmp;
   bool is_intrinsic_mvbits;
 
+  gcc_assert (code->resolved_sym);
+
+  /* Unfortunately, acc_attach* and acc_detach* need some special treatment for
+ attaching the the pointee to a pointer as GCC might introduce a temporary
+ array descriptor, whose data component is then used as to be attached to
+ pointer.  */
+  if (flag_openacc
+  && code->resolved_sym->attr.subroutine
+  && code->resolved_sym->formal
+  && code->resolved_sym->formal->sym->ts.type == BT_ASSUMED
+  && code->resolved_sym->formal->sym->attr.dimension
+  && code->resolved_sym->formal->sym->as->type == AS_ASSUMED_RANK
+  && startswith (code->resolved_sym->name, "acc_")
+  && (!strcmp (code->resolved_sym->name + 4, "attach")
+	  || !strcmp (code->resolved_sym->name + 4, "attach_async")
+	  || !strcmp (code->resolved_sym->name + 4, "detach")
+	  || !strcmp (code->resolved_sym->name + 4, "detach_async")
+	  || !strcmp (code->resolved_sym->name + 4, "detach_finalize")

Re: [PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

[Jerry D]

On 6/23/25 12:39 PM, Harald Anlauf wrote:

Dear all,

here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module.  One check
incorrectly referred to the original interface name, not the
renamed one.

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

Thanks,
Harald


Yes, all good. Thanks!

Jerry

Re: [PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

[Harald Anlauf]

Am 23.06.25 um 22:33 schrieb Jerry D:

On 6/23/25 12:39 PM, Harald Anlauf wrote:

Dear all,

here's an obvious fix for a rejects-valid when an interface was
renamed on use and is extended in the importing module.  One check
incorrectly referred to the original interface name, not the
renamed one.

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

Thanks,
Harald


Yes, all good. Thanks!


Thanks for the review!

Pushed as r16-1633-g6dd1659cf10a7a so far.

Harald


Jerry

[PATCH] gcc: remove atan from edom_only_function

[Yuao Ma]

Hi all,

This patch addresses previous review feedback by splitting the atan handling
into a separate patch.
This patch is part of 
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj

Please take a look when you are available. Thanks!

Best regards,
Yuao



0001-gcc-remove-atan-from-edom_only_function.patch
Description: 0001-gcc-remove-atan-from-edom_only_function.patch