[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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



--- Comment #13 from Juno Krahn  2012-11-30 17:21:08 
UTC ---

This issue was once discussed by members of the Fortran standards committee. I

don't recall if that was on usenet or somewhere in the committee meeting notes.

The conclusion was that it is useful to allow for multiple explicit interfaces

in order to interface correctly with C libraries, and that the standards allow

for it.



The standards state that the defined interface must be compatible with the C

routine, but there are multiple ways to define a single interface. For example,

a pointer argument can be a pass-by-reference or just a C pointer. It might

make sense to validate that each interface spec does in fact have the same

binary call signature. Depending on compiler internals, that may be difficult

to implement.



In any case, it might be good to keep this as an optional warning because it is

not that common and could in fact be an error.



As for previous comments, yes someone should report this problem to NAG and

IBM.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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



--- Comment #8 from Juno Krahn  2012-11-26 19:55:11 
UTC ---

Also, I should have mentioned that multiple interface specs used to work in Gnu

Fortran, and it still works in current Intel, Sun and Open64 Fortran compilers.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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



Juno Krahn  changed:



   What|Removed |Added



 CC||juno.krahn at nih dot gov



--- Comment #7 from Juno Krahn  2012-11-26 19:51:55 
UTC ---

IMHO, this is valid code regardless of whether the binary argument types can be

seen as equivalent. The standard is quite vague, but see my comment at bug

48858 comment 13. The standard defines that the binding label itself is a

unique global entity, but does not specify that the interface definition is

unique.

[Bug fortran/55356] New: ICE with TRANSFER of C_NULL_PTR

[juno.krahn at nih dot gov]

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



 Bug #: 55356

   Summary: ICE with TRANSFER of C_NULL_PTR

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: juno.kr...@nih.gov





Example code (bug.f90):



use iso_c_binding

type(C_ptr) :: p

p = transfer(C_NULL_ptr,p)

end





Result:

$ gfortran -c  bug.f90 

f951: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.





Seems likely related to bug 46974

[Bug fortran/55345] ICE with abstract interface type with use-renamed local names

[juno.krahn at nih dot gov]

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



--- Comment #2 from Juno Krahn  2012-11-16 15:56:24 
UTC ---

Abstract interfaces and rename aliasing are both seldom used, plus there is a

work-around, so I agree that there is no need for back porting.

[Bug fortran/55345] New: ICE with abstract interface type with use-renamed local names

[juno.krahn at nih dot gov]

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



 Bug #: 55345

   Summary: ICE with  abstract interface type with use-renamed

local names

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: juno.kr...@nih.gov





If an abstract interface type is renamed in the USE statement, and one of those

names includes the original name, an ICE can occur.



Example code (bug.f90):

--

module mod1

  abstract interface

subroutine func_t()

end subroutine func_t

  end interface

end module mod1

module bug

  use mod1, func_t=>func_t, func1_t=>func_t

end module bug

--



Result:

$ gfortran -c bug2.f90 

bug.f90:8:0: internal compiler error: in gfc_trans_use_stmts, at

fortran/trans-decl.c:3886

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.





If the two USE statements are switched, no ICE occurs. It also succeeds if the

rename statements are within an ONLY list.

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

[juno.krahn at nih dot gov]

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: unassig...@gcc.gnu.org

ReportedBy: juno.kr...@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.)

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[juno.krahn at nih dot gov]

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



Juno Krahn  changed:



   What|Removed |Added



 CC||juno.krahn at nih dot gov



--- Comment #13 from Juno Krahn  2012-11-13 18:14:43 
UTC ---

I just came across this issue, using code that used to compile under gfortran.



The standards reference in the previous comment is in reference to program

units, which includes binding labels. It asserts that global identifiers are

unique entities, but interface definitions are not program units. Multiple

interfaces can refer to the same unique. I don't have a reference, but I

remember this specific issue being discussed at one point with the Fortran

Standards committee, and the consensus was that multiple interfaces to a single

BIND(C) name is both valid and useful.