Bug 79311 - [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
Summary: [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 6.2.0
: P3 normal
Target Milestone: 8.0
Assignee: janus
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: Finalization
  Show dependency treegraph
 
Reported: 2017-01-31 22:30 UTC by DIL
Modified: 2017-05-10 14:59 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.9.4, 5.4.0, 6.3.0, 7.0
Last reconfirmed: 2017-02-01 00:00:00


Attachments
Source reproducer (20.56 KB, application/x-tar)
2017-01-31 22:30 UTC, DIL
Details

Note You need to log in before you can comment on or make changes to this bug.
Description DIL 2017-01-31 22:30:45 UTC
Created attachment 40641 [details]
Source reproducer

Below is the GFORTRAN internal compiler error backtrace I encountered. There are four source files in the attachment and a simple make script. Files dil_basic.F90, tensor_algebra.F90, and stsubs.F90 are just auxiliary utilities. The problematic source file is tensor_recursive.F90. There are three classes defined there: tens_signature_t, tens_shape_t, and tens_header_t. The latter class contains two components of the former types (tens_signature_t and tens_shape_t). While Final subroutines in the tens_signature_t and tens_shape_t compile fine, the Final subroutine in the composite class fails to compile with an internal compiler error (below). If you comment it in the type declaration (tens_header_t), it will compile. Please help fixing this issue:

f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1972
0x63e92a generate_finalization_wrapper
    ../../cray-gcc-6.2.0/gcc/fortran/class.c:1972
0x63e92a gfc_find_derived_vtab(gfc_symbol*)
    ../../cray-gcc-6.2.0/gcc/fortran/class.c:2404
0x63fcf5 finalize_component
    ../../cray-gcc-6.2.0/gcc/fortran/class.c:995
0x63ed9e generate_finalization_wrapper
    ../../cray-gcc-6.2.0/gcc/fortran/class.c:2128
0x63ed9e gfc_find_derived_vtab(gfc_symbol*)
    ../../cray-gcc-6.2.0/gcc/fortran/class.c:2404
0x6b02e0 gfc_resolve_finalizers
    ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:12198
0x6c5573 resolve_fl_derived
    ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13463
0x6c0476 resolve_symbol
    ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13762
0x6d9dbb do_traverse_symtree
    ../../cray-gcc-6.2.0/gcc/fortran/symbol.c:3926
0x6c36aa resolve_types
    ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:15555
0x6bf0df gfc_resolve(gfc_namespace*)
    ../../cray-gcc-6.2.0/gcc/fortran/resolve.c:15665
0x6aaaf4 gfc_parse_file()
    ../../cray-gcc-6.2.0/gcc/fortran/parse.c:6059
0x6ebed2 gfc_be_parse_file
    ../../cray-gcc-6.2.0/gcc/fortran/f95-lang.c:201
Comment 1 Martin Liška 2017-02-01 10:10:20 UTC
Confirmed, started to ICE with GCC 4.9.0.
Comment 2 Dominique d'Humieres 2017-02-05 14:52:44 UTC
The ICE disappears if I comment the two lines

          final:: tens_signature_dtor                        !dtor

but not the line

          final:: tens_header_dtor                                   !dtor `GCC/5.4.0 bug
Comment 3 Dominique d'Humieres 2017-02-05 15:11:16 UTC
Backtrace

    frame #11: 0x00000001000174be f951`gfc_find_derived_vtab(gfc_symbol*) + 3043 at class.c:1992
    frame #12: 0x00000001000168db f951`gfc_find_derived_vtab(derived=<unavailable>) + 8059
    frame #13: 0x000000010001867e f951`::finalize_component(expr=0x00000001428ec070, derived=<unavailable>, comp=0x00000001429065f0, stat=0x00000001428e89c0, fini_coarray=0x00000001428e1ad0, code=0x00007fff5fbfe198, sub_ns=0x0000000143069000) + 910 at class.c:1000
    frame #14: 0x00000001000178ec f951`gfc_find_derived_vtab(gfc_symbol*) + 609 at class.c:2147
    frame #15: 0x000000010001768b f951`gfc_find_derived_vtab(derived=<unavailable>) + 11563
    frame #16: 0x000000010009b5ee f951`::gfc_resolve_finalizers(derived=0x00000001429241b0, finalizable=0x0000000000000000) + 414 at resolve.c:12517
    frame #17: 0x00000001000aac78 f951`::resolve_fl_derived(sym=0x00000001429241b0) + 56 at resolve.c:13791
    frame #18: 0x00000001000a77b8 f951`::resolve_symbol(sym=0x00000001429241b0) + 1576 at resolve.c:14134
    frame #19: 0x00000001000c8f83 f951`::do_traverse_symtree(st=<unavailable>, st_func=<unavailable>, sym_func=(f951`::resolve_symbol(gfc_symbol *) at resolve.c:14044))(gfc_symtree *), void (*)(gfc_symbol *)) + 211 at symbol.c:4000
    frame #20: 0x00000001000a1b37 f951`::resolve_types(ns=0x0000000143802c00) + 439 at resolve.c:15994
    frame #21: 0x00000001000a6b8f f951`gfc_resolve(ns=0x0000000143802c00) + 63 at resolve.c:16107
    frame #22: 0x00000001000946c0 f951`gfc_parse_file() + 736 at parse.c:6191
    frame #23: 0x00000001000dd1dc f951`::gfc_be_parse_file() + 76 at f95-lang.c:204
    frame #24: 0x0000000100bed59a f951`::compile_file() + 58 at toplev.c:463
    frame #25: 0x00000001010c8282 f951`toplev::main(int, char**) + 1243 at toplev.c:1983
    frame #26: 0x00000001010c7da7 f951`toplev::main(this=0x00007fff5fbff2b0, argc=<unavailable>, argv=<unavailable>) + 887
    frame #27: 0x00000001010c9de9 f951`main(argc=2, argv=0x00007fff5fbff2f8) + 41 at main.c:39
Comment 4 Dominique d'Humieres 2017-02-06 14:05:57 UTC
Reduced test:

       module tensor_recursive
        implicit none

        type, public:: tens_signature_t
         contains
          final:: tens_signature_dtor
        end type tens_signature_t

        type, public:: tens_header_t
         type(tens_signature_t), private:: signature
         contains
          final:: tens_header_dtor
        end type tens_header_t

       contains

        subroutine tens_signature_dtor(this)
         implicit none
         type(tens_signature_t):: this
        end subroutine tens_signature_dtor

        subroutine tens_header_dtor(this)
         implicit none
         type(tens_header_t):: this
        end subroutine tens_header_dtor

       end module tensor_recursive

The code compiles if one of the 'final:: ...' is removed.
Comment 5 janus 2017-05-07 17:52:00 UTC
This draft patch fixes the ICE on comment 0 and comment 4:


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 247264)
+++ gcc/fortran/resolve.c	(working copy)
@@ -12385,26 +12385,23 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
   if (parent)
     gfc_resolve_finalizers (parent, finalizable);
 
-  /* Return early when not finalizable. Additionally, ensure that derived-type
-     components have a their finalizables resolved.  */
-  if (!derived->f2k_derived || !derived->f2k_derived->finalizers)
+  /* Ensure that derived-type components have a their finalizers resolved.  */
+  bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
+  for (c = derived->components; c; c = c->next)
+    if (c->ts.type == BT_DERIVED
+	&& !c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
+      {
+	bool has_final2 = false;
+	if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final2))
+	  return false;  /* Error.  */
+	has_final = has_final || has_final2;
+      }
+  /* Return early if not finalizable.  */
+  if (!has_final)
     {
-      bool has_final = false;
-      for (c = derived->components; c; c = c->next)
-	if (c->ts.type == BT_DERIVED
-	    && !c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
-	  {
-	    bool has_final2 = false;
-	    if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
-	      return false;  /* Error.  */
-	    has_final = has_final || has_final2;
-	  }
-      if (!has_final)
-	{
-	  if (finalizable)
-	    *finalizable = false;
-	  return true;
-	}
+      if (finalizable)
+	*finalizable = false;
+      return true;
     }
 
   /* Walk over the list of finalizer-procedures, check them, and if any one


Regtesting now ...
Comment 6 janus 2017-05-07 18:38:28 UTC
(In reply to janus from comment #5)
> This draft patch fixes the ICE on comment 0 and comment 4:
> 
> [..]
>
> Regtesting now ...

The regtest went pretty well, although I'm seeing these three failures:

FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original 
FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original 
FAIL: gfortran.dg/mvbits_7.f90   -O0   (test for warnings, line 28)

But I think they are unrelated and also occur without my patch. Will check.
Comment 7 janus 2017-05-07 19:04:39 UTC
(In reply to janus from comment #6)
> The regtest went pretty well, although I'm seeing these three failures:
> 
> FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original 
> FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original 
> FAIL: gfortran.dg/mvbits_7.f90   -O0   (test for warnings, line 28)
> 
> But I think they are unrelated and also occur without my patch. Will check.

Indeed I see those also on a clean trunk.
Comment 8 janus 2017-05-09 20:56:10 UTC
Author: janus
Date: Tue May  9 20:55:38 2017
New Revision: 247818

URL: https://gcc.gnu.org/viewcvs?rev=247818&root=gcc&view=rev
Log:
2017-05-09  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/79311
	* resolve.c (gfc_resolve_finalizers): Ensure that derived-type
	components have a their finalizers resolved, also if the superordinate
	type itself has a finalizer.

2017-05-09  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/79311
	* gfortran.dg/finalize_32.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/finalize_32.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 9 janus 2017-05-09 21:02:34 UTC
Fixed on 8-trunk with r247818. Closing.

Thanks for the report!
Comment 10 DIL 2017-05-10 14:59:07 UTC
Thanks for fixing.