Bug 46330 - [4.6 Regression] [OOP] ICE after revision 166368
Summary: [4.6 Regression] [OOP] ICE after revision 166368
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2010-11-06 14:37 UTC by Dominique d'Humieres
Modified: 2010-11-06 18:48 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-11-06 16:01:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2010-11-06 14:37:40 UTC
Starting at revision 166368, the following code

! http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/76f99e7fd4f3e772#
module type2_type 
 implicit none 
 type, abstract :: Type2 
    character :: typeName*(30) = "unknown" 
 end type Type2 
 end module type2_type 

 module extended2A_type 
 use type2_type 
 implicit none 
 type, extends(Type2) :: Extended2A 
    real(kind(1.0D0)) :: coeff1 = 1. 
    real(kind(1.0D0)) :: coeff2 = 2. 
 contains 
    procedure :: setCoeff1 => Extended2A_setCoeff1 
 end type Extended2A 
 contains 
    function Extended2A_new(c1, c2) result(typePtr_) 
       real(kind(1.0D0)), optional, intent(in) :: c1 
       real(kind(1.0D0)), optional, intent(in) :: c2 
       type(Extended2A), pointer  :: typePtr_ 
       type(Extended2A), save, allocatable, target  :: type_ 
       allocate(type_) 
       typePtr_ => null() 
       if (present(c1)) call type_%setCoeff1(c1) 
       typePtr_ => type_ 
       if ( .not.(associated (typePtr_))) then 
          stop 'Error initializing Extended2A Pointer.' 
       endif 
    end function Extended2A_new 
    subroutine Extended2A_setCoeff1(this,c1) 
       class(Extended2A) :: this 
       real(kind(1.0D0)), intent(in) :: c1 
       this% coeff1 = c1 
    end subroutine Extended2A_setCoeff1 
 end module extended2A_type 

 module type1_type 
 use type2_type 
 implicit none 
 type Type1 
    class(type2), pointer :: type2Ptr => null() 
 contains 
    procedure :: initProc => Type1_initProc 
 end type Type1 
 contains 
    function Type1_initProc(this) result(iError) 
       use extended2A_type 
       implicit none 
       class(Type1) :: this 
       integer :: iError 
          this% type2Ptr => extended2A_new() 
          if ( .not.( associated(this% type2Ptr))) then 
             iError = 1 
             write(*,'(A)') "Something Wrong." 
          else 
             iError = 0 
          endif 
    end function Type1_initProc 
 end module type1_type 

 program main 
 use type1_type 
 use extended2A_type 
 implicit none 
 integer :: iErr, i 
 integer :: numArgs 
 character, dimension(:), allocatable :: tempArgs*(100) 
 class(type1), allocatable :: thisType1 
 allocate (Type1::thisType1) 
 iErr = thisType1%initProc() 
 deallocate (thisType1% type2Ptr)  ! What happens here???  See questions below. 
! now the pointer should be dangling and needs to be nullified / reassigned 
 end program main 

gives an ICE:

[macbook] f90/bug% gfcp pointers_type_red.f90
pointers_type_red.f90: In function 'type1_initproc':
pointers_type_red.f90:53:0: internal compiler error: Segmentation fault

The backtrace is

(gdb) bt
#0  0x00000001000ccd68 in gfc_conv_variable (se=0x7fff5fbfd4a0, expr=0x1417316f0) at ../../p_work/gcc/fortran/trans-expr.c:578
#1  0x00000001000cc2df in gfc_trans_pointer_assignment (expr1=0x141731330, expr2=0x1417316f0) at ../../p_work/gcc/fortran/trans-expr.c:4800
(gdb) p expr->symtree
$2 = (gfc_symtree *) 0x0
Comment 1 janus 2010-11-06 15:30:00 UTC
(In reply to comment #0)
> Starting at revision 166368

... which was my commit implementing polymorphic deep copy:

http://gcc.gnu.org/viewcvs?view=revision&revision=166368

I'll have a look ...
Comment 2 janus 2010-11-06 16:01:29 UTC
Fixed by this one-liner:

Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c    (revision 166397)
+++ gcc/fortran/trans-expr.c    (working copy)
@@ -5925,7 +5925,7 @@ gfc_trans_class_assign (gfc_expr *expr1, gfc_expr
          gcc_assert (vtab);
          rhs = gfc_get_expr ();
          rhs->expr_type = EXPR_VARIABLE;
-         gfc_find_sym_tree (vtab->name, NULL, 1, &st);
+         gfc_find_sym_tree (vtab->name, vtab->ns, 1, &st);
          rhs->symtree = st;
          rhs->ts = vtab->ts;
        }


Will commit as obvious after a regression check.

Thanks for catching this, Dominique.
Comment 3 janus 2010-11-06 17:58:14 UTC
Author: janus
Date: Sat Nov  6 17:58:11 2010
New Revision: 166405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166405
Log:
2010-11-06  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46330
	* trans-expr.c (gfc_trans_class_assign): Find 'vtab' symbol in correct
	namespace.


2010-11-06  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46330
	* gfortran.dg/class_27.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_27.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 4 janus 2010-11-06 18:02:05 UTC
Fixed with r166405. Closing.
Comment 5 Dominique d'Humieres 2010-11-06 18:48:38 UTC
> Fixed with r166405. Closing.

Thanks for the quick fix.
An entry in gcc-patches@gcc.gnu.org for the patch may be missing.

Dominique