[PATCH] Fortran: fix ICE in check_host_association [PR108544]

[PATCH] Fortran: fix ICE in check_host_association [PR108544]

[Harald Anlauf]

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

Dear all,

the attached patch fixes two issues: first it addresses a NULL pointer
dereference on invalid input, triggered by the provided testcase.

Second, while analyzing the context of the affected code, I looked into
the testcase for PR96102, and by varying it slightly, i.e. replacing
functions by subroutines I found that we accept invalid code that is
rejected by several other brands tested.  To fix this, I removed one
line of a condition that did not seem to make sense to me.

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

Thanks,
Harald


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

From 59034b3b938a2f5e3391208fca56fcf54d5b6d18 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Wed, 25 Jan 2023 22:47:26 +0100
Subject: [PATCH] Fortran: fix ICE in check_host_association [PR108544]

gcc/fortran/ChangeLog:

	PR fortran/108544
	* resolve.cc (check_host_association): Extend host association check
	so that it is not restricted to functions.  Also prevent NULL pointer
	dereference.

gcc/testsuite/ChangeLog:

	PR fortran/108544
	* gfortran.dg/pr108544.f90: New test.
	* gfortran.dg/pr96102b.f90: New test.
---
 gcc/fortran/resolve.cc                 |  4 +++-
 gcc/testsuite/gfortran.dg/pr108544.f90 | 11 +++++++++++
 gcc/testsuite/gfortran.dg/pr96102b.f90 | 24 ++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr108544.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr96102b.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 94213cd3cd4..9e2edf7be71 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -6087,7 +6087,6 @@ check_host_association (gfc_expr *e)
       gfc_find_symbol (e->symtree->name, gfc_current_ns, 1, &sym);

       if (sym && old_sym != sym
-	      && sym->ts.type == old_sym->ts.type
 	      && sym->attr.flavor == FL_PROCEDURE
 	      && sym->attr.contained)
 	{
@@ -6132,6 +6131,9 @@ check_host_association (gfc_expr *e)
 		  return false;
 		}

+	      if (ref == NULL)
+		return false;
+
 	      gcc_assert (ref->type == REF_ARRAY);

 	      /* Grab the start expressions from the array ref and
diff --git a/gcc/testsuite/gfortran.dg/pr108544.f90 b/gcc/testsuite/gfortran.dg/pr108544.f90
new file mode 100644
index 00000000000..783cb7aaf7b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108544.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/108544 - ICE in check_host_association
+! Contributed by G.Steinmetz
+
+module m
+contains
+  subroutine s
+    select type (s => 1) ! { dg-error "Selector shall be polymorphic" }
+    end select
+  end
+end
diff --git a/gcc/testsuite/gfortran.dg/pr96102b.f90 b/gcc/testsuite/gfortran.dg/pr96102b.f90
new file mode 100644
index 00000000000..82147da3893
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr96102b.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+!
+! PR fortran/108544 - host association
+! Variation of testcase pr96102.f90 using subroutines instead of functions
+
+module m
+  type mytype
+    integer :: i
+  end type
+  type(mytype) :: d = mytype (42) ! { dg-error "is host associated" }
+  integer      :: n = 2           ! { dg-error "is host associated" }
+contains
+  subroutine s
+    if ( n   /= 0 ) stop 1  ! { dg-error "internal procedure of the same name" }
+    if ( d%i /= 0 ) stop 2  ! { dg-error "internal procedure of the same name" }
+  contains
+    subroutine n()
+    end
+    subroutine d()
+    end
+  end
+end
+
+! { dg-prune-output "Operands of comparison operator" }
--
2.35.3

Re: [PATCH] Fortran: fix ICE in check_host_association [PR108544]

[Steve Kargl]

On Wed, Jan 25, 2023 at 10:59:22PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
> 
> the attached patch fixes two issues: first it addresses a NULL pointer
> dereference on invalid input, triggered by the provided testcase.
> 
> Second, while analyzing the context of the affected code, I looked into
> the testcase for PR96102, and by varying it slightly, i.e. replacing
> functions by subroutines I found that we accept invalid code that is
> rejected by several other brands tested.  To fix this, I removed one
> line of a condition that did not seem to make sense to me.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 

Yes.  I briefly looked at this by simply commenting out
the assert, which gives too many odd error messages.
Returning 'false' seems to  be best.

-- 
Steve