[PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]

[PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]

[Harald Anlauf]

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

Dear All,

the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict between an internal procedure and
a local declaration for the case that the latter is a derived type.
Another torture test by Gerhard... ;-)  Used to ICE previously.

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

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr110957.diff --]
[-- Type: text/x-patch, Size: 3044 bytes --]

From 75dc455f21cea07e64b422c9994ab8879df388de Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Fri, 6 Oct 2023 22:21:56 +0200
Subject: [PATCH] fortran: fix handling of options -ffpe-trap and -ffpe-summary
 [PR110957]

gcc/fortran/ChangeLog:

	PR fortran/110957
	* invoke.texi: Update documentation to reflect '-ffpe-trap=none'.
	* options.cc (gfc_handle_fpe_option): Fix mixup up of error messages
	for options -ffpe-trap and -ffpe-summary.  Accept '-ffpe-trap=none'
	to clear FPU traps previously set on command line.
---
 gcc/fortran/invoke.texi | 6 ++++--
 gcc/fortran/options.cc  | 9 ++++++---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 38150b1e29e..10387e39501 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1294,7 +1294,8 @@ Specify a list of floating point exception traps to enable.  On most
 systems, if a floating point exception occurs and the trap for that
 exception is enabled, a SIGFPE signal will be sent and the program
 being aborted, producing a core file useful for debugging.  @var{list}
-is a (possibly empty) comma-separated list of the following
+is a (possibly empty) comma-separated list of either @samp{none} (to
+clear the set of exceptions to be trapped), or of the following
 exceptions: @samp{invalid} (invalid floating point operation, such as
 @code{SQRT(-1.0)}), @samp{zero} (division by zero), @samp{overflow}
 (overflow in a floating point operation), @samp{underflow} (underflow
@@ -1314,7 +1315,8 @@ If the option is used more than once in the command line, the lists will
 be joined: '@code{ffpe-trap=}@var{list1} @code{ffpe-trap=}@var{list2}'
 is equivalent to @code{ffpe-trap=}@var{list1},@var{list2}.

-Note that once enabled an exception cannot be disabled (no negative form).
+Note that once enabled an exception cannot be disabled (no negative form),
+except by clearing all traps by specifying @samp{none}.

 Many, if not most, floating point operations incur loss of precision
 due to rounding, and hence the @code{ffpe-trap=inexact} is likely to
diff --git a/gcc/fortran/options.cc b/gcc/fortran/options.cc
index 27311961325..2ad22478042 100644
--- a/gcc/fortran/options.cc
+++ b/gcc/fortran/options.cc
@@ -555,9 +555,12 @@ gfc_handle_fpe_option (const char *arg, bool trap)
 	pos++;

       result = 0;
-      if (!trap && strncmp ("none", arg, pos) == 0)
+      if (strncmp ("none", arg, pos) == 0)
 	{
-	  gfc_option.fpe_summary = 0;
+	  if (trap)
+	    gfc_option.fpe = 0;
+	  else
+	    gfc_option.fpe_summary = 0;
 	  arg += pos;
 	  pos = 0;
 	  continue;
@@ -586,7 +589,7 @@ gfc_handle_fpe_option (const char *arg, bool trap)
 	      break;
 	    }
 	  }
-      if (!result && !trap)
+      if (!result && trap)
 	gfc_fatal_error ("Argument to %<-ffpe-trap%> is not valid: %s", arg);
       else if (!result)
 	gfc_fatal_error ("Argument to %<-ffpe-summary%> is not valid: %s", arg);
--
2.35.3

Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]

[Harald Anlauf]

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

Dear All,

sorry for attaching the wrong patch - this time it is the correct one!

Harald

On 10/11/23 21:39, Harald Anlauf wrote:
> Dear All,
>
> the attached trivial patch fixes (= catches) a forgotten corner-case
> in the detection of a name conflict between an internal procedure and
> a local declaration for the case that the latter is a derived type.
> Another torture test by Gerhard... ;-)  Used to ICE previously.
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> Thanks,
> Harald
>

[-- Attachment #2: pr104351.diff --]
[-- Type: text/x-patch, Size: 2724 bytes --]

From 84de03c97f899df91f2b7e7af4a5bbc09412a3fe Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Wed, 11 Oct 2023 21:29:35 +0200
Subject: [PATCH] Fortran: name conflict between internal procedure and derived
 type [PR104351]

gcc/fortran/ChangeLog:

	PR fortran/104351
	* decl.cc (get_proc_name): Extend name conflict detection between
	internal procedure and previous declaration also to derived type.

gcc/testsuite/ChangeLog:

	PR fortran/104351
	* gfortran.dg/derived_function_interface_1.f90: Adjust pattern.
	* gfortran.dg/pr104351.f90: New test.
---
 gcc/fortran/decl.cc                                |  4 +++-
 .../gfortran.dg/derived_function_interface_1.f90   |  2 +-
 gcc/testsuite/gfortran.dg/pr104351.f90             | 14 ++++++++++++++
 3 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr104351.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 4a3c5b86de0..bdd3be32a46 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1404,7 +1404,9 @@ get_proc_name (const char *name, gfc_symbol **result, bool module_fcn_entry)
       /* Trap declarations of attributes in encompassing scope.  The
 	 signature for this is that ts.kind is nonzero for no-CLASS
 	 entity.  For a CLASS entity, ts.kind is zero.  */
-      if ((sym->ts.kind != 0 || sym->ts.type == BT_CLASS)
+      if ((sym->ts.kind != 0
+	   || sym->ts.type == BT_CLASS
+	   || sym->ts.type == BT_DERIVED)
 	  && !sym->attr.implicit_type
 	  && sym->attr.proc == 0
 	  && gfc_current_ns->parent != NULL
diff --git a/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90 b/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
index 24a00950912..5438ad49c6a 100644
--- a/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
+++ b/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
@@ -38,7 +38,7 @@ end function ext_fun
 
 contains
 
-  type(foo) function fun() ! { dg-error "already has an explicit interface" }
+  type(foo) function fun() ! { dg-error "has an explicit interface" }
   end function fun  ! { dg-error "Expecting END PROGRAM" }
 
 end
diff --git a/gcc/testsuite/gfortran.dg/pr104351.f90 b/gcc/testsuite/gfortran.dg/pr104351.f90
new file mode 100644
index 00000000000..86b47e03340
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104351.f90
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/104351
+! Contributed by G.Steinmetz
+
+program p
+  implicit none
+  type t
+  end type
+  type(t) :: f
+contains
+  real function f() result(z) ! { dg-error "has an explicit interface" }
+    z = 0.0                   ! { dg-error "assignment" }
+  end function f              ! { dg-error "Expecting END PROGRAM" }
+end
-- 
2.35.3

Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]

[Jerry D]

On 10/11/23 12:39 PM, Harald Anlauf wrote:
> Dear All,
> 
> the attached trivial patch fixes (= catches) a forgotten corner-case
> in the detection of a name conflict between an internal procedure and
> a local declaration for the case that the latter is a derived type.
> Another torture test by Gerhard... ;-)  Used to ICE previously.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 
> Thanks,
> Harald
> 

This one is OK Harald.

Thanks,

Jerry

Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]

[Jerry D]

On 10/11/23 12:44 PM, Harald Anlauf wrote:
> Dear All,
> 
> sorry for attaching the wrong patch - this time it is the correct one!
> 
> Harald
> 
> On 10/11/23 21:39, Harald Anlauf wrote:
>> Dear All,
>>
>> the attached trivial patch fixes (= catches) a forgotten corner-case
>> in the detection of a name conflict between an internal procedure and
>> a local declaration for the case that the latter is a derived type.
>> Another torture test by Gerhard... ;-)  Used to ICE previously.
>>
>> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>>
>> Thanks,
>> Harald
>>

This one is OK as well. Once I found the right patch on the right email. 
  Regardless, both good to go.

Thanks,

Jerry