Bug 47730 - [OOP] ICE on invalid source in connection with SELECT TYPE
[OOP] ICE on invalid source in connection with SELECT TYPE
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: janus
: ice-on-invalid-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-14 09:43 UTC by Arjen Markus
Modified: 2011-02-14 22:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-02-14 10:23:13


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arjen Markus 2011-02-14 09:43:45 UTC
The code below produces an ICE after reporting that assign_square must be a module procedure or an external procedure. It seems related to bug #46849

module geometrical_objects

   implicit none

   type, abstract :: shape
   end type shape

   type, extends(shape) :: rectangle
       real :: width, height
   end type rectangle

   type, extends(rectangle) :: square
   contains
       procedure ::  assign_square
   end type square

contains

  subroutine assign_rectangle( this, that )
    class(shape),     intent(inout) :: this
    class(rectangle), intent(in)    :: that
    select type( that )
      class is (rectangle)
    end select
  end subroutine assign_rectangle

  subroutine assign_square( this, that )
    class(shape),  intent(inout) :: this
    class(square), intent(in)    :: that
  end subroutine assign_square

end module geometrical_objects
Comment 1 janus 2011-02-14 10:23:13 UTC
(In reply to comment #0)
> The code below produces an ICE after reporting that assign_square must be a
> module procedure or an external procedure.

Not quite. For me, the exact output is:

       procedure ::  assign_square
                1
Error: Argument 'this' of 'assign_square' with PASS(this) at (1) must be of the derived-type 'square'
f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:3426


I think throwing the error is correct, but of course the ICE should not occur.
Comment 2 janus 2011-02-14 10:27:23 UTC
(In reply to comment #0)
> It seems related to bug #46849

Yes, in particular to comment #2 in that PR:

module m
  implicit none
  type :: dt
  end type
contains
  subroutine test(fun)
    class(dt) :: fun
    call extern(not_existing) ! Error: No implicit type
    select type (fun)
    type is (dt)          ! TYPE IS is required for the ICE
    end select
  end subroutine test
end module m


which gives:

    call extern(not_existing) ! Error: No implicit type
                            1
Error: Symbol 'not_existing' at (1) has no IMPLICIT type
f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:3426


Same pattern: Some error, and afterwards an ICE in 'gfc_enforce_clean_symbol_state'.
Comment 3 janus 2011-02-14 10:32:18 UTC
Another related test case was recently reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2011-02/msg00111.html:


module mod1
  type treeNode
  end type treeNode
contains
  subroutine proc1(thisNode)
    class (treeNode), target, intent(in) :: thisNode
    select type (thisNode)
    type is (treeNode)
       workNode => thisNode
    end select
  end subroutine proc1
end module mod1


workNode => thisNode
       1
Error: Non-POINTER in pointer association context (pointer assignment) at (1)
f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:3426
Comment 4 janus 2011-02-14 21:05:56 UTC
The following patch fixes the ICE in all three test cases and regtests cleanly:

Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 170150)
+++ gcc/fortran/parse.c	(working copy)
@@ -3154,6 +3154,7 @@ gfc_build_block_ns (gfc_namespace *parent_ns)
       t = gfc_add_flavor (&my_ns->proc_name->attr, FL_LABEL,
 			  my_ns->proc_name->name, NULL);
       gcc_assert (t == SUCCESS);
+      gfc_commit_symbol (my_ns->proc_name);
     }
 
   if (parent_ns->proc_name)


Will commit as obvious.
Comment 5 janus 2011-02-14 22:17:47 UTC
Author: janus
Date: Mon Feb 14 22:17:44 2011
New Revision: 170157

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170157
Log:
2011-02-14  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47730
	* parse.c (gfc_build_block_ns): Commit 'block@' symbol.

2011-02-14  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47730
	* gfortran.dg/select_type_22.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/select_type_22.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/parse.c
    trunk/gcc/testsuite/ChangeLog
Comment 6 janus 2011-02-14 22:19:19 UTC
Fixed with r170157. Closing.

Thanks for the reports, guys!