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.
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.
It looks like a duplicate of the unfixed part of pr43945.
(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.
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?
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
Close as FIXED. Thanks Salvatore for the test case and thanks Janus for the patch.
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.
(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