The following test case shows that functions which return derived-types/polymorphic arrays are mishandled. Failures: * For many: Error: Can't convert REAL(4) to TYPE(t) * For instance: *(atmp[0].data) = *f_type() ! ups null pointer deref * Memory not freed for funcs returning allocatable memory. Note: One problem is that the functions can occur in nested constructors, ac-do loops, having unknown ac-do loop bounds array sizes. program main implicit none type t end type t interface function f_type() import :: t type(t), allocatable :: f_type end function f_type function f_type_na() import :: t type(t) :: f_type end function f_type_na function f_type_array() import :: t type(t), allocatable :: f_type(:) end function f_type_array function f_type_array_na() import :: t type(t) :: f_type(5) end function f_type_array_na function f_class(i) import :: t class(t), allocatable :: f_class integer :: i end function f_class function f_class_array() import :: t class(t), allocatable :: f_class integer :: i end function f_class_array subroutine sub_type2(x) import :: t type(t) :: x(:) end subroutine sub_type2 subroutine sub_class2(x) import :: t class(t) :: x(:) end subroutine sub_class2 end interface type(t) :: b(1) integer :: i b = [ f_type() ] b = [ f_type_na() ] b = [ f_type_array() ] b = [ f_type_array_na() ] b = [ f_class_array(1) ] call sub_type2([f_class(1)]) call sub_type2([f_class_array(1)]) call sub_type2([(f_class(i),i=1,5)]) call sub_type2([(f_class_array(i),i=1,5)]) call sub_class2([f_class(1)]) call sub_class2([f_class_array(1)]) call sub_class2([(f_class(i),i=1,5)]) call sub_class2([(f_class_array(i),i=1,5)]) end program main
Also the following fails: call sub_class2(f_type_array())
I think the conversion errors are simply due to declaration issues in the test case, e.g.: program main implicit none type t end type t interface function f_type_na() import :: t type(t) :: f_type end function end interface type(t) :: b b = f_type_na() end program b = f_type_na() 1 Error: Can't convert REAL(4) to TYPE(t) at (1) But the following variant yields a different error: program main implicit none type t end type t type(t) :: b b = f_type_na() contains function f_type_na() type(t) :: f_type end function end program function f_type_na() 1 Error: Contained function 'f_type_na' at (1) has no IMPLICIT type c0.f90:11.6: b = f_type_na() 1 Error: Can't convert UNKNOWN to TYPE(t) at (1) Apparently we apply implicit typing to the INTERFACE version (although IMPLICIT NONE is given).
Here is a 'corrected' version of the test case: program main implicit none type t end type t interface function f_type() import :: t type(t), allocatable :: f_type end function function f_type_na() import :: t type(t) :: f_type_na end function function f_type_array() import :: t type(t), allocatable :: f_type_array(:) end function function f_type_array_na() import :: t type(t) :: f_type_array_na(5) end function function f_class(i) import :: t class(t), allocatable :: f_class integer :: i end function function f_class_array(i) import :: t class(t), allocatable :: f_class_array(:) integer :: i end function subroutine sub_type2(x) import :: t type(t) :: x(:) end subroutine subroutine sub_class2(x) import :: t class(t) :: x(:) end subroutine end interface type(t) :: b(1) integer :: i b = [ f_type() ] b = [ f_type_na() ] b = [ f_type_array() ] b = [ f_type_array_na() ] b = [ f_class_array(1) ] call sub_type2([f_class(1)]) call sub_type2([f_class_array(1)]) call sub_type2([(f_class(i),i=1,5)]) call sub_type2([(f_class_array(i),i=1,5)]) call sub_class2([f_class(1)]) call sub_class2([f_class_array(1)]) call sub_class2([(f_class(i),i=1,5)]) call sub_class2([(f_class_array(i),i=1,5)]) end program main which yields with 4.9 trunk: c0.f90:51:0: internal compiler error: in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1472 b = [ f_class_array(1) ] ^ 0x63078f gfc_trans_array_constructor_subarray /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:1472 0x63078f gfc_trans_array_constructor_value /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:1601 0x62f216 trans_array_constructor /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:2323 0x62f216 gfc_add_loop_ss_code /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:2558 0x62f955 gfc_conv_loop_setup(gfc_loopinfo*, locus*) /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:4683 0x64c001 gfc_trans_assignment_1 /home/jweil/gcc49/trunk/gcc/fortran/trans-expr.c:7913 0x61e795 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1623 0x63dee2 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5605 0x5de510 translate_all_program_units /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4536 0x5de510 gfc_parse_file() /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4733 0x61adb5 gfc_be_parse_file /home/jweil/gcc49/trunk/gcc/fortran/f95-lang.c:188 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
(In reply to janus from comment #3) > Here is a 'corrected' version of the test case: > > [...] > > which yields with 4.9 trunk: > > c0.f90:51:0: internal compiler error: in > gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1472 > b = [ f_class_array(1) ] The ICE is gone since version 7. The only problems that might still be existing are the memory leaks mentioned in comment 0 (haven't checked).