[PATCH] fortran: error recovery on duplicate declaration of class variable [PR95710]

[PATCH] fortran: error recovery on duplicate declaration of class variable [PR95710]

[Harald Anlauf]

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

Dear all,

the attached simple and obvious patch fixes several NULL pointer
dereferences that are encountered for a duplicate declaration of
a class variable.  Another one from Gerhard's torture tests...

Regtested on x86_64-pc-linux-gnu.

I intend to commit within 24h unless there are comments.

Thanks,
Harald


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

From 0027c58c172889bdb5c09ecea0faf3c48624dc21 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Fri, 22 Sep 2023 21:06:00 +0200
Subject: [PATCH] fortran: error recovery on duplicate declaration of class
 variable [PR95710]

gcc/fortran/ChangeLog:

	PR fortran/95710
	* class.cc (gfc_build_class_symbol): Do not try to build class
	container for invalid typespec.
	* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
	dereference.
	(resolve_symbol): Likewise.

gcc/testsuite/ChangeLog:

	PR fortran/95710
	* gfortran.dg/pr95710.f90: New test.
---
 gcc/fortran/class.cc                  |  4 ++++
 gcc/fortran/resolve.cc                |  4 +++-
 gcc/testsuite/gfortran.dg/pr95710.f90 | 17 +++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr95710.f90

diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index 9d0c802b867..5c43b77dba3 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -647,6 +647,10 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,

   gcc_assert (as);

+  /* We cannot build the class container now.  */
+  if (attr->class_ok && (!ts->u.derived || !ts->u.derived->components))
+    return false;
+
   /* Class container has already been built with same name.  */
   if (attr->class_ok
       && ts->u.derived->components->attr.dimension >= attr->dimension
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 1042b8c18e8..861f69ac20f 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -13326,6 +13326,7 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
 	  && sym->ts.u.derived
 	  && !sym->attr.select_type_temporary
 	  && !UNLIMITED_POLY (sym)
+	  && CLASS_DATA (sym)
 	  && CLASS_DATA (sym)->ts.u.derived
 	  && !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
 	{
@@ -16068,7 +16069,8 @@ resolve_symbol (gfc_symbol *sym)
       specification_expr = saved_specification_expr;
     }

-  if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived)
+  if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived
+      && CLASS_DATA (sym))
     {
       as = CLASS_DATA (sym)->as;
       class_attr = CLASS_DATA (sym)->attr;
diff --git a/gcc/testsuite/gfortran.dg/pr95710.f90 b/gcc/testsuite/gfortran.dg/pr95710.f90
new file mode 100644
index 00000000000..566c38d0a9d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95710.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/95710 - ICE on duplicate declaration of class variable
+! Contributed by G.Steinmetz
+
+module m
+  interface
+     module function s()
+     end
+  end interface
+end
+submodule(m) m2
+contains
+  module function s()
+    class(*), allocatable :: x
+    class(*), allocatable :: x ! { dg-error "Unclassifiable statement" }
+  end
+end
--
2.35.3

Re: [PATCH] fortran: error recovery on duplicate declaration of class variable [PR95710]

[Bernhard Reutner-Fischer]

On 22 September 2023 21:16:35 CEST, Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote:
>Dear all,
>
>the attached simple and obvious patch fixes several NULL pointer
>dereferences that are encountered for a duplicate declaration of
>a class variable.  Another one from Gerhard's torture tests...

Obviously ok.
thanks,

>
>Regtested on x86_64-pc-linux-gnu.
>
>I intend to commit within 24h unless there are comments.
>
>Thanks,
>Harald
>