Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28701 Discussions

Platform dependant behaviour with BIND(C)

alexanpe99
Beginner
759 Views
I have inherited a C++ and Fortran model that was originally written for Windows and I am trying to port to Linux. I'm not particularly experienced with Fortran and having some problems with that side. Had hoped that using the linux complier on both platforms would mean the fortran problems would be slight. The following coding pattern worked using the Intel Windows complier, however fails to complie on the Intel Linux complier.
[fortran]Module Test

INTERFACE
        SUBROUTINE GTitle(STRING) BIND(C)
        USE,INTRINSIC :: ISO_C_BINDING
                CHARACTER(KIND=C_CHAR), DIMENSION(*) :: STRING [REFERENCE]
        END SUBROUTINE
END INTERFACE

contains

Subroutine SubTest()
        Call GTitle('Some Name'C)
End Subroutine SubTest

End Module Test
[/fortran]
On linux I get the following:
ifort -od -fpp -openmp_stubs -align rec1byte -align commons -assume byterecl -mixed_str_len_arg -traceback -threads -c Test2.f90
Test2.f90(13): error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [STRING]
Call GTitle('Some Name'C)
-------------^
compilation aborted for Test2.f90 (code 1)
ifort -od -fpp -openmp_stubs -align rec1byte -align commons -assume byterecl -mixed_str_len_arg -traceback -threads -c Test2.f90Test2.f90(13): error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [STRING] Call GTitle('Some Name'C)-------------^compilation aborted for Test2.f90 (code 1)
Any assistance would be much appreciated.
Thanks
Peter
0 Kudos
10 Replies
Steven_L_Intel1
Employee
759 Views
I can't reproduce this - which compiler version are you using? ifort -V will tell you. I would be very surprised by a platform difference in this area.
0 Kudos
alexanpe99
Beginner
759 Views
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20090131 Package ID: l_cprof_p_11.0.081
0 Kudos
Steven_L_Intel1
Employee
759 Views
That's pretty old. Can you try a newer one? Which version is your Windows system using?
0 Kudos
alexanpe99
Beginner
759 Views

Not easy to upgrading on Linux as I'm just a user on a large infrastructure, however I will put in a request for a newer version to be made avaliable. On Windows it was ComposerXE-2011 installed around April.

However it appears that part (perhaps all) of the problem may be due to unnecessaryDimension(*). If this is removed it complies (and initial indications is works at run time) on both platforms.

Still doesn't explain the platform differences, if it works them I'm happy.


0 Kudos
Lorri_M_Intel
Employee
759 Views
Probably not platform differences, as much as compiler-version differences.

That is, we fixed something in the Composer XE 2011 version that was broken in the older compiler (from 2009)

-- Lorri
0 Kudos
jimdempseyatthecove
Honored Contributor III
759 Views
Wouldn't you want:

CHARACTER(KIND=C_CHAR, LEN=*) :: STRING ! [REFERENCE]

*** note the ! before [REFERENCE]

The way you had it declared would have specified was for an array of 1 character elements (size of array assumed), *** and as a coarray of size = REFERENCE (?undeclared parameter).

The above declares a scalar character variable of assumed length.

Your "Call GTitle('Some Name'C)" is passing a scalar character variable of length 9 (10 w/NULL)

Jim Dempsey
0 Kudos
Steven_L_Intel1
Employee
759 Views
No - for an "interoperable" procedure, an array of length 1 character is correct. There is no REFERENCE attribute in standard Fortran.

The Fortran standard carefully specifies that a character (any length argument) can be passed to a character(1) array - this is an exception to the rule that normally forbids passing scalars to arrays.

To be honest, I would be somewhat astonished that we ever had such a bug, as this is a major item in the C interoperabilty features we introduced in 10.0, but I suppose anything is possible...
0 Kudos
jimdempseyatthecove
Honored Contributor III
759 Views
>>No - for an "interoperable" procedure, an array of length 1 character is correct.

However, the user is seeing the error message complaining about a FORTRAN'scalar'C passed to a FORTRAN subroutine declared taking an array. Although this is a valid FORTRAN standards call, their IVF is in error reporting this (a bug in their older version of IVF). Further the user's C (C++) code is not going to see the FORTRAN INTERFACE. Therefore to keep the user's version of IVF "happy" they can declare the FORTRAN INTERFACE differently (without affecting the C/C++ side of the application). Alternativley they could buy an update.

Jim Dempsey
0 Kudos
alexanpe99
Beginner
759 Views
Got access to 12.0 and indeed the problem is not seen in that complier version. I'm therefore presuming it would be best to keep the fortran interface declaration as per the original code. Thanks for all your help.
0 Kudos
Steven_L_Intel1
Employee
759 Views
If he modified the interface as you suggest, Jim, it would be detected as an error by a newer version and would be non-standard.
0 Kudos
Reply