[PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

[PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

[Harald Anlauf]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Dear all,

Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic.  The standard allows such recursive references
(see e.g. F2018:19.3.1).

The attached patch is based on Steve's, but handles both functions
and subroutines.  Testcase verified with NAG and Crayftn.

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

This bug is a rejects-valid, but could also lead to wrong code,
see e.g. the PR, comment#4.  Would this qualify for a backport
to e.g. the 11-branch?

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fortran-a-RECURSIVE-procedure-cannot-be-an-INTRINSIC.patch --]
[-- Type: text/x-patch, Size: 1971 bytes --]

From 4c23f78a41fad7cb19aeeeed84c99a73d761fa02 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Mon, 4 Apr 2022 20:42:51 +0200
Subject: [PATCH] Fortran: a RECURSIVE procedure cannot be an INTRINSIC

gcc/fortran/ChangeLog:

	PR fortran/105138
	* intrinsic.cc (gfc_is_intrinsic): When a symbol refers to a
	RECURSIVE procedure, it cannot be an INTRINSIC.

gcc/testsuite/ChangeLog:

	PR fortran/105138
	* gfortran.dg/recursive_reference_3.f90: New test.

Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
---
 gcc/fortran/intrinsic.cc                           |  1 +
 .../gfortran.dg/recursive_reference_3.f90          | 14 ++++++++++++++
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/recursive_reference_3.f90

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 2339d9050ec..e89131f5a71 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -1164,6 +1164,7 @@ gfc_is_intrinsic (gfc_symbol* sym, int subroutine_flag, locus loc)

   /* Check for attributes which prevent the symbol from being INTRINSIC.  */
   if (sym->attr.external || sym->attr.contained
+      || sym->attr.recursive
       || sym->attr.if_source == IFSRC_IFBODY)
     return false;

diff --git a/gcc/testsuite/gfortran.dg/recursive_reference_3.f90 b/gcc/testsuite/gfortran.dg/recursive_reference_3.f90
new file mode 100644
index 00000000000..f4e2963aec2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/recursive_reference_3.f90
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! { dg-options "-std=f2018" }
+! PR fortran/105138 - recursive procedures and shadowing of intrinsics
+
+RECURSIVE FUNCTION LOG_GAMMA(Z) RESULT(RES)
+  COMPLEX, INTENT(IN) :: Z
+  COMPLEX             :: RES
+  RES = LOG_GAMMA(Z)
+END FUNCTION LOG_GAMMA
+
+recursive subroutine date_and_time (z)
+  real :: z
+  if (z > 0) call date_and_time (z-1)
+end subroutine date_and_time
--
2.34.1

Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

[Jerry D]

On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote:
> Dear all,
>
> Steve's analysis (see PR) showed that we confused the case when a
> symbol refererred to a recursive procedure which was named the same
> as an intrinsic.  The standard allows such recursive references
> (see e.g. F2018:19.3.1).
>
> The attached patch is based on Steve's, but handles both functions
> and subroutines.  Testcase verified with NAG and Crayftn.
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> This bug is a rejects-valid, but could also lead to wrong code,
> see e.g. the PR, comment#4.  Would this qualify for a backport
> to e.g. the 11-branch?
>
> Thanks,
> Harald
>
Yes, looks good, OK to commit

Regards,

Jerry

Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

[Thomas Koenig]

Hi Harald,

> Steve's analysis (see PR) showed that we confused the case when a
> symbol refererred to a recursive procedure which was named the same
> as an intrinsic.  The standard allows such recursive references
> (see e.g. F2018:19.3.1).
> 
> The attached patch is based on Steve's, but handles both functions
> and subroutines.  Testcase verified with NAG and Crayftn.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 
> This bug is a rejects-valid, but could also lead to wrong code,
> see e.g. the PR, comment#4.  Would this qualify for a backport
> to e.g. the 11-branch?

OK for both.

Thanks for the patch!

Best regards

	Thomas