Fortran: ICE on recursive derived types with allocatable components [PR107872]

Message ID trinity-896fac60-06d8-49ed-9a30-56ae2e8b7c7f-1670621235681@3c-app-gmx-bs62
State Accepted
Headers
Series Fortran: ICE on recursive derived types with allocatable components [PR107872] |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Harald Anlauf Dec. 9, 2022, 9:27 p.m. UTC
  Dear all,

I am submitting the attached simple - and obvious - patch on
behalf of Paul.  It prevents a resource exhaustion due to an
infinite loop, and has been regtested by multiple contributers, ;-)
at least on x86_64-pc-linux-gnu.

I intend to commit it to mainline within 24 hours, unless
there are further comments.

Thanks,
Harald
  

Comments

Paul Richard Thomas Dec. 9, 2022, 9:58 p.m. UTC | #1
Hi Harald,

Thanks for doing that. My attention is elsewhere gfortran-wise.

Good for mainline.

Paul


On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran <fortran@gcc.gnu.org>
wrote:

> Dear all,
>
> I am submitting the attached simple - and obvious - patch on
> behalf of Paul.  It prevents a resource exhaustion due to an
> infinite loop, and has been regtested by multiple contributers, ;-)
> at least on x86_64-pc-linux-gnu.
>
> I intend to commit it to mainline within 24 hours, unless
> there are further comments.
>
> Thanks,
> Harald
>
>
  

Patch

From 01254aa2eb766c7584fd047568d7277d4d65d067 Mon Sep 17 00:00:00 2001
From: Paul Thomas <pault@gcc.gnu.org>
Date: Fri, 9 Dec 2022 22:13:45 +0100
Subject: [PATCH] Fortran: ICE on recursive derived types with allocatable
 components [PR107872]

gcc/fortran/ChangeLog:

	PR fortran/107872
	* resolve.cc (derived_inaccessible): Skip over allocatable components
	to prevent an infinite loop.

gcc/testsuite/ChangeLog:

	PR fortran/107872
	* gfortran.dg/pr107872.f90: New test.
---
 gcc/fortran/resolve.cc                 |  3 +-
 gcc/testsuite/gfortran.dg/pr107872.f90 | 40 ++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr107872.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 75dc4b59105..158bf08ec26 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -7536,7 +7536,8 @@  derived_inaccessible (gfc_symbol *sym)
   for (c = sym->components; c; c = c->next)
     {
 	/* Prevent an infinite loop through this function.  */
-	if (c->ts.type == BT_DERIVED && c->attr.pointer
+	if (c->ts.type == BT_DERIVED
+	    && (c->attr.pointer || c->attr.allocatable)
 	    && sym == c->ts.u.derived)
 	  continue;

diff --git a/gcc/testsuite/gfortran.dg/pr107872.f90 b/gcc/testsuite/gfortran.dg/pr107872.f90
new file mode 100644
index 00000000000..09838479e92
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107872.f90
@@ -0,0 +1,40 @@ 
+! { dg-do run }
+!
+! Test the fix for PR107872, where an ICE occurred in
+! resolve.cc(derived_inaccessible) because derived types with
+! recursive allocatable components were not catered for.
+!
+module mod1
+  type t
+     integer :: data
+     type(t), allocatable :: next
+   contains
+     procedure, private :: write_t
+     generic :: write(formatted) => write_t
+  end type
+contains
+  recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
+    class(t), intent(in) :: this
+    integer, intent(in) :: unit
+    character(*), intent(in) :: iotype
+    integer, intent(in) :: v_list(:)
+    integer, intent(out) :: iostat
+    character(*), intent(inout) :: iomsg
+    if (ALLOCATED(this%next)) &
+         write (unit, '(dt)') this%next
+    write (unit, '(i2)') this%data
+  end subroutine
+end module
+
+  use mod1
+  type(t) :: a
+  character (8) :: buffer
+  a%data = 1
+  allocate (a%next)
+  a%next%data = 2
+  allocate (a%next%next)
+  a%next%next%data = 3
+  write (buffer, '(dt)')a
+  deallocate (a%next)
+  if (trim (buffer) .ne. ' 3 2 1') stop 1
+end
--
2.35.3