http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-04-29 09:24:30 UTC --- Created attachment 24141 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24141 Example 2, cf. comment 3, third item (In reply to comment #2) > See http://gcc.gnu.org/ml/fortran/2011-04/msg00293.html for a variant > which ICE (segfaults) after printing the error. (With 4.7.0 20110428 [compiled with release checking], I do not see the ICE.) ( Note: The thread continues at http://gcc.gnu.org/ml/fortran/2011-04/msg00294.html ) * * * I have thought about the question again - and now I think that gfortran 4.6/4.7 correctly rejects the program as ambiguous, even though ifort 12.0, crayftn 7.3, PGI and gfortran 4.5 accept it. For: function add_vector_2d( point, vector ) class(point2d), intent(in) :: point class(point2d), intent(in) :: vector function add_vector_3d( point, vector ) class(point3d), intent(in) :: point type(point3d), intent(in) :: vector I believe the interfaces are ambiguous as: "Two dummy arguments are distinguishable if [...] neither is TKR compatible with the other" (F2008, 12.4.3.4.5) For an actual argument of the type "class(point3d),type(point3d)", either function has the correct interface. More precisely, class(point2d) is type compatible* with class(point3d) and class(point2d) is type compatible with type(point3d). -- The crucial word is "neither": While add_vector_3d's dummies are not type compatible to add_vector_2d - the reverse is not true. Thus, the arguments are not distinguishable. (* A polymorphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same declared type or any of its extensions.", F2008, 4.3.1.3.) * * * If one modifies the program (cf. attachment 24110) as follows, gfortran 4.7 segfaults at ==30150== Invalid read of size 8 ==30150== at 0x4CB104: gfc_compare_derived_types (interface.c:409) ==30150== by 0x52ACCE: gfc_type_is_extension_of (symbol.c:4700) ==30150== by 0x52AD8E: gfc_type_compatible (symbol.c:4728) --- hj44.f90 2011-04-29 10:38:53.663239782 +0200 +++ hj444.f90 2011-04-29 10:39:39.111745236 +0200 @@ -17,3 +17 @@ - procedure :: add_vector_3dversion => add_vector_3d - generic, public :: add_vector_new => add_vector_3dversion - generic, public :: operator(+) => add_vector_3dversion + procedure :: add_vector => add_vector_3d @@ -38 +36 @@ - type(point2d) :: add_vector_2d + class(point2d) :: add_vector_2d @@ -47 +45 @@ - type(point3d), intent(in) :: vector + class(point3d), intent(in) :: vector @@ -49 +47 @@ - type(point3d) :: add_vector_3d + class(point3d) :: add_vector_3d * * * Regarding a second program at http://gcc.gnu.org/ml/fortran/2011-04/msg00302.html (see example 2 attachment): The program compiles and segfault at run time for function add_vector_2d( point, vector ) class(point2d), intent(in) :: point, vector class(point2d), allocatable :: add_vector_2d if ( allocated(add_vector_2d) ) then deallocate( add_vector_2d ) endif allocate( add_vector_2d ) The issue is that the result variable is not properly initialized; from the dump: struct __class_points2d3d_Point2d_a __result_add_vector_2d; if (__result_add_vector_2d._data != 0B)
