[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #11 from klaas_giesbertz at hotmail dot com --- Finally figured out how to make it work. I guess this is what the class(*) is useful for. Using class(*) I can simply overload Func and its resolution becomes dynamic. I consider the class(*) quite an overkill, but it works. So the Base and Derived Modules now become module BaseModule implicit none private type, public :: BaseClass contains procedure :: Func end type contains subroutine Func(self, other) class(BaseClass), intent(inout) :: self class(*), intent(in):: other write(*,*) 'Base Func called' end subroutine end module module DerivedModule use BaseModule implicit none private type, public, extends(BaseClass) :: DerivedClass real :: x contains procedure :: Func end type contains subroutine Func(self, other) class(DerivedClass), intent(inout) :: self class(*),intent(in):: other write(*,*) 'Derived Func called' select type(bla = other) class is (DerivedClass) write(*,*) 'DerivedClass found' class default write(*,*) 'Bad luck' end select end subroutine end module
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to klaas_giesbertz from comment #11) Finally figured out how to make it work. I guess this is what the class(*) is useful for. Using class(*) I can simply overload Func and its resolution becomes dynamic. I consider the class(*) quite an overkill, but it works. I don't think you need unlimited polymorphism, i.e. class(*), for what you're trying to do. It should be enough to declare the 'other' argument as 'class(BaseClass)' in both cases.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #13 from klaas_giesbertz at hotmail dot com --- You are right! Thanks a lot.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #14 from janus at gcc dot gnu.org --- In any case I will close this PR now, since I don't see any problems with gfortran's behavior on the test cases reported here.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #1 from klaas_giesbertz at hotmail dot com --- Sorry, the 2nd argument of Init of UseBase in the 1st test should have been target instead of pointer. In that case 'program Test' becomes the same as in the 2nd test.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to klaas_giesbertz from comment #0) This code compiles and runs correctly with gcc4.7.3, but gcc4.8.2 gives the following compile error: Test1.f08:58.13: procedure :: Func 1 Error: Argument mismatch for the overriding procedure 'func' at (1): Type/rank mismatch in argument 'other' For your first example, I get this error with all version from 4.6 to trunk (with slight variations in the wording). Are you sure the code you posted is what you compiled with 4.7? I actually do not even know if this code is supposed to compile, since it is not clear to me if such kind of overloading is allowed by the fortran standard. I think the error is correct. The Fortran standard does not allow this.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to klaas_giesbertz from comment #0) This code compiles both with gcc4.7.3 and gcc4.8.2 and gives in both cases the incorrect output: Base Func called It should have called the DerivedFunc instead. The second example is a bit tricky. Note that the resolution of your generic 'Func' happens at compile time and only based on the declared type -- the dynamic type of the objects does not matter at all. I would say the behavior here is ok as well.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #4 from klaas_giesbertz at hotmail dot com --- In reply to Comment23 (Janus): I have copied it back from my post and it still compiles with my gfortran4.7.3. Could it have something to do with my build of gcc? I used macports to install it on my machine, so I am not fully aware of the dependencies. Would be strange though. Anyway, it is wrong fortran, so it should not work. A 'select type' could make the distinction, so 'select type' works dynamically, but the generic works statically. Confusing. So you would say that this kind of functionality is out of reach for fortran2008? Do you have any idea for a different solution? I know this is not the place to ask, but I would be grateful for some help.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to klaas_giesbertz from comment #4) I have copied it back from my post and it still compiles with my gfortran4.7.3. Could it have something to do with my build of gcc? Hopefully not, but it might have to do with the exact version. I just tried it with the most recent branch build: gcc version 4.7.4 20131219 (prerelease) [gcc-4_7-branch revision 206127] (GCC) (which yields the same result as the 4.7.3 version provided by Ubuntu, namely rejecting the test case). What does gfortran -v show in your case?
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-19 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test in comment 0 compiles with 4.7.3 and gives at run time Derived Func called And I confirm the reported behavior for the rest of the posts.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) The test in comment 0 compiles with 4.7.3 and gives at run time Is this with the proper 4.7.3 release or some 4.7 branch build? Can you give the excact version (gfortran -v)? As mentioned in comment 5, it is being rejected with a current 4.7 branch build for me. Some commit on the 4.7 branch might have affected the behavior?
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) Some commit on the 4.7 branch might have affected the behavior? After a quick look into the ChangeLog, I already have a suspicion: 2013-06-01 Janus Weil ja...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR fortran/57217 * interface.c (check_dummy_characteristics): Symmetrize type check.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- When I say 4.7.3 it means the 4.7.3 release, otherwise I give the revision number or the date if the former is not available.
[Bug fortran/59560] Resolution generic procedure of derived types fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59560 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) When I say 4.7.3 it means the 4.7.3 release, otherwise I give the revision number or the date if the former is not available. Ok, that matches my suspicion (as that commit was after the 4.7.3 release).
