pgf90 problems compiling BIND(C) function.

pgf90 (10.6) gives the following error when trying to compile the code below:

PGF90-S-0044-Multiple declaration for symbol info_t (testcall.f90: 14)
0 inform, 0 warnings, 1 severes, 0 fatal for liter_cb

when I take the function out of the module it compiles fine.

MODULE liter_cb_mod

USE ISO_C_BINDING

CONTAINS

FUNCTION liter_cb(link_info) bind©

USE ISO_C_BINDING
IMPLICIT NONE

INTEGER(c_int) liter_cb

TYPE, bind© :: info_t
INTEGER(c_int) :: type
END TYPE info_t

TYPE(info_t) :: link_info

liter_cb = 0

END FUNCTION liter_cb

END MODULE liter_cb_mod

PROGRAM main

END PROGRAM main

Hi Breitenfeld,

The error in the program is that you’re using “BIND©” on a TYPE. Bind© is only allowed on procedures and external global variables. Changing "TYPE, bind© :: info_t " to “TYPE :: info_t” will allow it compile.

The compiler error is not detecting this syntax error and instead generating multiple declarations for info_t. I have submitted a problem report (TPR#17165) to detect this error and give a better message.

Thanks,
Mat

I’m a bit confused what you mean, I’m following the Fortran 2003 standard, if you look at section 15.2.3 Interoperability of derived types and C struct types:

2 A Fortran derived type is interoperable if it has the BIND attribute.

And it clearly shows in NOTE 15.14 the convention I used:

USE, INTRINSIC :: ISO_C_BINDING
TYPE, BIND© :: MYFTYPE
INTEGER(C_INT) :: I, J
REAL(C_FLOAT) :: S
END TYPE MYFTYPE

The suggestion you make is not standard compatable and breaks on other compilers.

If the type declaration is moved to the module scope the code compiles.

MODULE liter_cb_mod

USE ISO_C_BINDING

TYPE, BIND© :: MYFTYPE
INTEGER(C_INT) :: I, J
REAL(C_FLOAT) :: S
END TYPE MYFTYPE

CONTAINS

FUNCTION liter_cb() bind©

USE ISO_C_BINDING
IMPLICIT NONE

INTEGER(c_int) liter_cb

TYPE(MYFTYPE) :: link_info

liter_cb = 0

END FUNCTION liter_cb

END MODULE liter_cb_mod

There was a discussion about the matter in comp.lang.fortran under the topic
“BIND© functions in a module error” as to the source of the problem if interested.

Hi Breitenfeld,

My sincere apologies. I had missed this section and agree that this is valid code.

After discussing the issue with our lead compiler Architect, we also agree that the error is compiler issue that appears to only occur in this scenario. I’ve updated TPR#17165 with this information and we will assign a compiler engineer to investigate further.

Best Regards,
Mat

This TPR was corrected in the current 10.9 release. Thanks for your submission.

regards,
dave