Bug 54243 - [OOP] ICE (segfault) in gfc_type_compatible for invalid BT_CLASS
Summary: [OOP] ICE (segfault) in gfc_type_compatible for invalid BT_CLASS
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: error-recovery, ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2012-08-13 14:50 UTC by Sylwester Arabas
Modified: 2012-09-04 08:03 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-08-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylwester Arabas 2012-08-13 14:50:14 UTC
With Deabian's gcc-snapshot gfortran (4.8.0 20120714) trying to compile to code below:



module aqq_m
  type :: aqq_t
    contains
    procedure :: aqq_init
  end type 
  contains
  subroutine aqq_init(this)
    class(aqq_t) :: this
  end subroutine
end module
program bug2
  use aqq_m
  class(aqq_t) :: aqq
  call aqq%aqq_init
end program



I get:



$ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form  bug2.f
bug2.f:24.21:

  class(aqq_t) :: aqq
                     1   
Error: CLASS variable 'aqq' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.



HTH,
Sylwester
Comment 1 Tobias Burnus 2012-08-13 15:35:11 UTC
Segfaults in

4837    gfc_type_compatible (gfc_typespec *ts1, gfc_typespec *ts2)
4838    {
4839      bool is_class1 = (ts1->type == BT_CLASS);
4840      bool is_class2 = (ts2->type == BT_CLASS);
...
4853      else if (is_class1 && is_class2)
4854        return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
4855                                         ts2->u.derived->components->ts.u.derived);

The problem is that ts2->u.derived->components == NULL.
Comment 2 janus 2012-08-13 19:21:15 UTC
I think the proper fix for both this one and PR 54244 would be the following:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 190186)
+++ gcc/fortran/resolve.c	(working copy)
@@ -5793,6 +5795,9 @@ check_typebound_baseobject (gfc_expr* e)
 
   gcc_assert (base->ts.type == BT_DERIVED || base->ts.type == BT_CLASS);
 
+  if (base->ts.type == BT_CLASS && !gfc_expr_attr (base).class_ok)
+    return FAILURE;
+
   /* F08:C611.  */
   if (base->ts.type == BT_DERIVED && base->ts.u.derived->attr.abstract)
     {


This aborts the resolution of the type-bound call rather early (if the passed object was not properly declared), avoiding all problems that one could possibly run into later. It is also general enough that it should work for other similar cases.
Comment 3 janus 2012-08-14 21:27:25 UTC
The patch in comment 2 regresses on typebound_operator_11.f90, which can be fixed by the following:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 190186)
+++ gcc/fortran/resolve.c	(working copy)
@@ -237,6 +237,7 @@ resolve_procedure_interface (gfc_symbol *sym)
       sym->attr.always_explicit = ifc->attr.always_explicit;
       sym->attr.ext_attr |= ifc->attr.ext_attr;
       sym->attr.is_bind_c = ifc->attr.is_bind_c;
+      sym->attr.class_ok = ifc->attr.class_ok;
       /* Copy array spec.  */
       sym->as = gfc_copy_array_spec (ifc->as);
       if (sym->as)
@@ -11982,6 +11986,7 @@ resolve_fl_derived0 (gfc_symbol *sym)
 	      c->attr.recursive = ifc->attr.recursive;
 	      c->attr.always_explicit = ifc->attr.always_explicit;
 	      c->attr.ext_attr |= ifc->attr.ext_attr;
+	      c->attr.class_ok = ifc->attr.class_ok;
 	      /* Replace symbols in array spec.  */
 	      if (c->as)
 		{
Comment 4 janus 2012-08-15 22:11:15 UTC
Author: janus
Date: Wed Aug 15 22:11:03 2012
New Revision: 190420

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190420
Log:
2012-08-15  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/54243
	PR fortran/54244
	* resolve.c (check_typebound_baseobject): Check for class_ok attribute.
	(resolve_procedure_interface,resolve_fl_derived0): Copy class_ok
	attribute.

2012-08-15  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/54243
	PR fortran/54244
	* gfortran.dg/typebound_call_24.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/typebound_call_24.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 5 janus 2012-08-15 22:19:14 UTC
Fixed with r190420. Closing.

Thanks for the report!
Comment 6 janus 2012-09-04 08:03:18 UTC
Author: janus
Date: Tue Sep  4 08:03:09 2012
New Revision: 190910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190910
Log:
2012-09-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/54435
	PR fortran/54443
	* match.c (gfc_match_select_type): Make sure to only access CLASS_DATA
	for BT_CLASS.

2012-09-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/54243
	PR fortran/54244
	* gfortran.dg/select_type_29.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/select_type_29.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/testsuite/ChangeLog