Bug 44434

Summary: [OOP] ICE in in gfc_add_component_ref
Product: gcc Reporter: Salvatore Filippone <sfilippone>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: gcc-bugs, janus, pault
Priority: P3 Keywords: ice-on-valid-code
Version: 4.6.0   
Target Milestone: ---   
Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu Known to work:
Known to fail: Last reconfirmed: 2010-06-06 16:16:37
Attachments: test case

Description Salvatore Filippone 2010-06-06 12:04:55 UTC
The attached code produces the following error output 
[sfilippo@localhost bug18]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20100605 (experimental) (GCC) 
[sfilippo@localhost bug18]$ gfortran  -c bug18.f03
bug18.f03:76:0: internal compiler error: in gfc_add_component_ref, at fortran/class.c:77
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 Salvatore Filippone 2010-06-06 12:07:03 UTC
Created attachment 20850 [details]
test case

If the CLASS DEFAULT block is switched to use AA%CSGET() instead of A%A%CSGET() no ICE ensues. 
I am not sure whether this is legal, but it is accepted by both IBM XLF and NAG.
Comment 2 Dominique d'Humieres 2010-06-06 12:18:22 UTC
It looks like a duplicate of the unfixed part of pr43945.
Comment 3 janus 2010-06-06 16:16:36 UTC
(In reply to comment #2)
> It looks like a duplicate of the unfixed part of pr43945.

It is. One can reduce the test case here to something equivalent to PR 43945 comment #12, which is:

module foo_mod
  type foo
  contains
    procedure :: doit
    generic :: do => doit
  end type
contains
  subroutine  doit(a) 
    class(foo) :: a
  end subroutine
end module

program testd15
contains
  subroutine dodo(x)
    use foo_mod
    class(foo) :: x
    call x%do()
  end subroutine
end


We can track the issue in this PR, and I'll close the other one.
Comment 4 janus 2010-06-08 01:19:58 UTC
The backtrace for comment #3 is:

#0  gfc_add_component_ref (e=0x1806e80, name=0x7ffff7e7ceb8 "doit") at /home/jweil/gcc46/trunk/gcc/fortran/class.c:77
#1  0x000000000052b323 in resolve_typebound_subroutine (code=0x1806bf0) at /home/jweil/gcc46/trunk/gcc/fortran/resolve.c:5530
#2  0x0000000000530ed4 in resolve_code (code=0x1806bf0, ns=0x17fb030) at /home/jweil/gcc46/trunk/gcc/fortran/resolve.c:8454
#3  0x000000000053acfa in resolve_codes (ns=0x17fb030) at /home/jweil/gcc46/trunk/gcc/fortran/resolve.c:12837
#4  0x000000000053abeb in resolve_codes (ns=0x17febe0) at /home/jweil/gcc46/trunk/gcc/fortran/resolve.c:12823
#5  0x000000000053adf5 in gfc_resolve (ns=0x17febe0) at /home/jweil/gcc46/trunk/gcc/fortran/resolve.c:12864
#6  0x0000000000519bbf in gfc_parse_file () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4275
#7  0x000000000055a7bb in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/trunk/gcc/fortran/f95-lang.c:234
#8  0x0000000000a19514 in compile_file () at /home/jweil/gcc46/trunk/gcc/toplev.c:1042
#9  0x0000000000a1b80e in do_compile () at /home/jweil/gcc46/trunk/gcc/toplev.c:2407
#10 0x0000000000a1b8e4 in toplev_main (argc=2, argv=0x7fffffffe2b8) at /home/jweil/gcc46/trunk/gcc/toplev.c:2449
#11 0x00000000005e28b0 in main (argc=2, argv=0x7fffffffe2b8) at /home/jweil/gcc46/trunk/gcc/main.c:35


Apparently the problem is that the generic's vtype still is '$empty', while it should be 'vtype$foo$do'. Paul, can you remind me why we even need this $empty thing?
Comment 5 janus 2010-07-13 06:57:38 UTC
Subject: Bug 44434

Author: janus
Date: Tue Jul 13 06:57:17 2010
New Revision: 162125

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

	PR fortran/44434
	PR fortran/44565
	PR fortran/43945
	PR fortran/44869
	* gfortran.h (gfc_find_derived_vtab): Modified prototype.
	* class.c (gfc_build_class_symbol): Modified call to
	'gfc_find_derived_vtab'.
	(add_proc_component): Removed, moved code into 'add_proc_comp'.
	(add_proc_comps): Renamed to 'add_proc_comp', removed treatment of
	generics.
	(add_procs_to_declared_vtab1): Removed unnecessary argument 'resolved'.
	Removed treatment of generics.
	(copy_vtab_proc_comps): Removed unnecessary argument 'resolved'.
	Call 'add_proc_comp' instead of duplicating code.
	(add_procs_to_declared_vtab): Removed unnecessary arguments 'resolved'
	and 'declared'.
	(add_generic_specifics,add_generics_to_declared_vtab): Removed.
	(gfc_find_derived_vtab): Removed unnecessary argument 'resolved'.
	Removed treatment of generics.
	* iresolve.c (gfc_resolve_extends_type_of): Modified call to
	'gfc_find_derived_vtab'.
	* resolve.c (resolve_typebound_function,resolve_typebound_subroutine):
	Removed treatment of generics.
	(resolve_select_type,resolve_fl_derived): Modified call to
	'gfc_find_derived_vtab'.
	* trans-decl.c (gfc_get_symbol_decl): Ditto.
	* trans-expr.c (gfc_conv_derived_to_class,gfc_trans_class_assign):
	Ditto.
	* trans-stmt.c (gfc_trans_allocate): Ditto.

2010-07-13  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/44434
	PR fortran/44565
	PR fortran/43945
	PR fortran/44869
	* gfortran.dg/dynamic_dispatch_1.f03: Fixed invalid test case.
	* gfortran.dg/dynamic_dispatch_2.f03: Ditto.
	* gfortran.dg/dynamic_dispatch_3.f03: Ditto.
	* gfortran.dh/typebound_call_16.f03: New.
	* gfortran.dg/typebound_generic_6.f03: New.
	* gfortran.dg/typebound_generic_7.f03: New.
	* gfortran.dg/typebound_generic_8.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/typebound_call_16.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_generic_6.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_generic_7.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_generic_8.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/iresolve.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_1.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_2.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_3.f03

Comment 6 Tobias Burnus 2010-07-13 08:25:28 UTC
Close as FIXED. Thanks Salvatore for the test case and thanks Janus for the patch.
Comment 7 Tobias Burnus 2010-07-13 08:32:08 UTC
I just saw that both ifort and crayftn reject the program of comment 1 (ambiguous interface); I have now filled PR 44434 to track this.
Comment 8 Tobias Burnus 2010-07-13 08:33:11 UTC
(In reply to comment #7)
> I just saw that both ifort and crayftn reject the program of comment 1
> (ambiguous interface); I have now filled PR 44434 to track this.

Make that: PR 44926