Bug 45900 - [OOP] Static TBP resolved incorrectly
[OOP] Static TBP resolved incorrectly
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: 4.6.4
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-05 19:53 UTC by ortp21
Modified: 2013-01-09 14:32 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-10-05 21:00:31


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ortp21 2010-10-05 19:53:47 UTC
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)
Comment 1 janus 2010-10-05 21:00:31 UTC
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).
Comment 2 janus 2010-10-05 21:42:15 UTC
(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.
Comment 3 ortp21 2010-10-05 22:01:08 UTC
(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.
Comment 4 Mikael Morin 2013-01-06 15:50:24 UTC
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
Comment 5 Mikael Morin 2013-01-08 19:42:50 UTC
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
Comment 6 Mikael Morin 2013-01-08 20:01:59 UTC
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
Comment 7 Mikael Morin 2013-01-09 14:32:41 UTC
Fixed for 4.6.4  4.7.3  4.8.0.
Thanks for the bug report.