The following example code provides an incorrect result using gfortran 4.6.0 20100925. I believe the code is valid and I have tested the same code with the Intel Fortran compiler (ifort) 11.1 on Linux and the results returned are correct. See the below example: types.f90 --------------------------------------------------------- module A implicit none type :: aType contains procedure :: callback end type aType contains subroutine callback( callback_ ) implicit none class(aType) :: callback_ print *, "Error: aType method called." end subroutine callback subroutine solver( callback_ ) implicit none class(aType) :: callback_ call callback_%callback() end subroutine solver end module A module B use A, only: aType implicit none type, extends(aType) :: bType integer :: i contains procedure :: callback end type bType contains subroutine callback( callback_ ) implicit none class(bType) :: callback_ print *, "Made it." end subroutine callback end module B program main use A use B implicit none type(bType) :: bTypeInstance integer :: iflag bTypeInstance%i = 4 call bTypeInstance%callback() call solver( bTypeInstance ) end program main --------------------------------------------------------- The result produced running this code are found to be: $ gfortran -o t types.f90 $ ./t Error: aType method called. Made it. While ifort correctly produces the result: Made it. Made it. A workaround is to do change "use A" in the main to: use A, only: solver Using built-in specs. COLLECT_GCC=gfortran Target: x86_64-apple-darwin10.4.0 Configured with: ../gcc-4.6-20100925/configure --prefix=~$HOME/gcc-trunk --enable-languages=fortran --enable-checking=release --disable-bootstrap Thread model: posix gcc version 4.6.0 20100925 (experimental) (GCC)
Confirmed. This is basically a duplicate of PR45836. The TBP call here is non-polymorphic, since the type of the passed object is fixed at compile time. The problem is that it is resolved to the wrong procedure (due to the procedures having the same name).
(In reply to comment #1) > Confirmed. This is basically a duplicate of PR45836. Both are also related to PR42769. I'm currently not sure how to fix this. The obvious workaround is to use different names for the procedures.
(In reply to comment #2) > (In reply to comment #1) > > Confirmed. This is basically a duplicate of PR45836. > > Both are also related to PR42769. The reason I posted this bug report as well is that PR45836 returned a compiler error (type mismatch), while this case does not, and actually lets an incorrect result through. I hope it was worth another report. Thanks.
Author: mikael Date: Sun Jan 6 15:50:09 2013 New Revision: 194949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_23.f90 trunk/gcc/testsuite/gfortran.dg/use_24.f90 trunk/gcc/testsuite/gfortran.dg/use_25.f90 trunk/gcc/testsuite/gfortran.dg/use_26.f90 trunk/gcc/testsuite/gfortran.dg/use_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Author: mikael Date: Tue Jan 8 19:42:38 2013 New Revision: 195031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/module.c branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Author: mikael Date: Tue Jan 8 20:01:49 2013 New Revision: 195032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Fixed for 4.6.4 4.7.3 4.8.0. Thanks for the bug report.