[Bug fortran/55343] New: Renamed C_PTR entities are not treated as equivalent types.

["juno.krahn at nih dot gov" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55343

             Bug #: 55343
           Summary: Renamed C_PTR entities are not treated as equivalent
                    types.
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: juno.krahn@nih.gov


When the intrinsic C_PTR type is accessed via a local name, it is no longer
treated as equivalent to the C_PTR type under either the original name or any
other different local name.

Example code: (test_rename.f90)
---------------------
module my_mod
  implicit none
  type int_type
    integer :: i
  end type int_type
end module my_mod
program main
  use iso_c_binding, only: C_void_ptr=>C_ptr, C_string_ptr=>C_ptr
  use my_mod, only: i1_type=>int_type, i2_type=>int_type
  implicit none
  type(C_string_ptr) :: p_string
  type(C_void_ptr) :: p_void
  type (i1_type) :: i1
  type (i2_type) :: i2
  p_void = p_string
  i1 = i2
end program main
-------------------------------

Result:
$ gfortran -c test_rename.f90
test_rename.f90:15.11:

  p_void = p_string
           1
Error: Can't convert TYPE(c_string_ptr) to TYPE(c_void_ptr) at (1)


I included a user defined derived type to illustrate that the equivalence of
renamed entities in that case works as expected. This used to work in Gnu
fortran, but I don't know what version I was using at that time.

(For comparison: Intel compilers handle it correctly. The latest Sun/Oracle
works when assigning from C_PTR to a renamed entity, but not the other way
around.)