Bug 35945 - Complex module-based overloading fails
Summary: Complex module-based overloading fails
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-04-15 15:15 UTC by Jonathan Hogg
Modified: 2008-09-24 08:14 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.4.0
Last reconfirmed: 2008-07-29 19:33:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Hogg 2008-04-15 15:15:06 UTC
If a type is renamed on import and then an unrenamed copy is also imported, and overloaded functions are called then gfortran fails to compile with a blocked by an incompatible object error. The code compiles cleanly with {NAG, ifort, g95}.

Not sure if this is a bug or non-standard code, though I suspect the former.

Thanks,
Joanthan Hogg

Full test case:
[user@host] ~/bugs/gfortran-4.3/import_rename  $ make
gfortran-4.3  -c stype.f90
gfortran-4.3  -c dtype.f90
gfortran-4.3  -c test.f90
test.f90:15.29:

   subroutine fred(sval, dval)
                            1
test.f90:16.15:

      use stype
              2
Error: The type 'overloaded_type' cannot be host associated at (1) because it is blocked by an incompatible object of the same name declared at (2)
make: *** [test.o] Error 1
[user@host] ~/bugs/gfortran-4.3/import_rename  $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[user@host] ~/bugs/gfortran-4.3/import_rename  $ cat test.f90 
program test
   use stype, overloaded_type_s => overloaded_type
   use dtype, overloaded_type_d => overloaded_type
   implicit none

   type(overloaded_type_s) :: sval
   type(overloaded_type_d) :: dval

   sval%part = 1
   dval%part = 2

   call fred(sval, dval)

contains
   subroutine fred(sval, dval)
      use stype

      type(overloaded_type_s), intent(in) :: sval
      type(overloaded_type_d), intent(in) :: dval

      call overloaded_sub(sval)
      call overloaded_sub(dval)
   end subroutine
end program
[user@host] ~/bugs/gfortran-4.3/import_rename  $ cat stype.f90 
module stype
   implicit none
   
   type overloaded_type
      real :: part
   end type

   interface overloaded_sub
      module procedure overloaded_sub_s
   end interface

contains
   subroutine overloaded_sub_s(otype)
      type(overloaded_type), intent(in) :: otype

      print *, "s type = ", otype%part
   end subroutine
end module
[user@host] ~/bugs/gfortran-4.3/import_rename  $ cat dtype.f90 
module dtype
   implicit none
   
   type overloaded_type
      double precision :: part
   end type

   interface overloaded_sub
      module procedure overloaded_sub_d
   end interface

contains
   subroutine overloaded_sub_d(otype)
      type(overloaded_type), intent(in) :: otype

      print *, "d type = ", otype%part
   end subroutine
end module
Comment 1 Daniel Franke 2008-07-29 19:33:03 UTC
Confirmed, Lahey accepts it also.
(If 'use stype' in function 'fred' is commented, the testcase compiles cleanly).

Judging from Joost's initial description in PR32834, I assume this is one of that kind.
Comment 2 Paul Thomas 2008-09-18 20:22:27 UTC
Subject: Bug 35945

Author: pault
Date: Thu Sep 18 20:21:03 2008
New Revision: 140474

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140474
Log:
2008-09-18  Paul Thomas  <pault@gcc.gnu.org>

       PR fortran/35945
       * resolve.c (resolve_fl_variable_derived):  Remove derived type
       comparison for use associated derived types.  Host association
       of a derived type will not arise if there is a local derived type
       whose use name is the same.

       PR fortran/36700
       * match.c (gfc_match_call):  Use the existing symbol even if
       it is a function.

2008-09-18  Paul Thomas  <pault@gcc.gnu.org>

       PR fortran/35945
       * gfortran.dg/host_assoc_types_2.f90: New test.

       PR fortran/36700
       * gfortran.dg/host_assoc_call_2.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90
    trunk/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

Comment 3 Paul Thomas 2008-09-24 08:14:11 UTC
Subject: Bug 35945

Author: pault
Date: Wed Sep 24 08:12:47 2008
New Revision: 140627

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140627
Log:
2008-09-24  Paul Thomas  <pault@gcc.gnu.org>

       PR fortran/35945
       * resolve.c (resolve_fl_variable_derived):  Remove derived type
       comparison for use associated derived types.  Host association
       of a derived type will not arise if there is a local derived type
       whose use name is the same.

       PR fortran/36700
       * match.c (gfc_match_call):  Use the existing symbol even if
       it is a function.

2008-09-24  Paul Thomas  <pault@gcc.gnu.org>

       PR fortran/35945
       * gfortran.dg/host_assoc_types_2.f90: New test.

       PR fortran/36700
       * gfortran.dg/host_assoc_call_2.f90: New test.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/match.c
    branches/gcc-4_3-branch/gcc/fortran/resolve.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

Comment 4 Paul Thomas 2008-09-24 08:14:53 UTC
Fixed on trunk and 4.3

Thanks for the report

Paul