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

Compiler errors in V12 not present in earlier versions

lklawrie
Beginner
901 Views

Compiling with Intel Visual Fortran Compiler XE 12.0.0.104 [IA-32]...

ExternalInterface.f90

D:\\EPPgm\\DBL_Source\\ExternalInterface.f90(303): error #8532: A character dummy argument with length other than 1 is not interoperable. [FILENAME]


The code is:
INTERFACE
INTEGER(C_INT) FUNCTION establishclientsocket(fileName) BIND (C, NAME="establishclientsocket")
! Returns the logical unit number of the socket
USE ISO_C_BINDING, ONLY: C_INT, C_CHAR
CHARACTER(kind=C_CHAR, len=*) :: fileName ! file from which socket port number will be read
END FUNCTION establishclientsocket
END INTERFACE

Is this an error on the V12 compiler or something we need to find a work around for? (or a rewrite of the interface code -- which is really part of a different system)?

Linda

0 Kudos
8 Replies
mecej4
Honored Contributor III
901 Views
The only character types that are C-interoperable are of length 1, according to the Fortran standard. This rule is enforced not only by IFort 12, but also by IFort 11.1, and by other compilers such as GFortran.

You can, however, change

[fortran]CHARACTER(kind=C_CHAR, len=*) :: fileName
[/fortran]
to

[bash]CHARACTER(kind=C_CHAR), dimension(*) :: fileName
[/bash]

and let the rules of sequence association work for you.
0 Kudos
lklawrie
Beginner
901 Views
Thanks, will give that a try.

Linda
0 Kudos
lklawrie
Beginner
901 Views
This did work for me (compiles at least -- others will have to test) but I don't understand why this was an ERROR with the compiler rather than a warning?

I don't have "standards checking" turned on and certainly don't have standards warnings as errors turned on.

Linda
0 Kudos
mecej4
Honored Contributor III
901 Views
You wrote: "I don't understand why this was an ERROR with the compiler rather than a warning".

Speaking as a user of ISO_C_BINDING, I think that I should expect ERROR rather than WARNING. Had we been discussing interoperability of C and Fortran-77, a situation in which the programmer had the entire responsibility of making the C and Fortran interoperate, WARNING (more usually, not even a warning could be expected) would have been appropriate. The Fortran compiler did not know anything about C, and vice-versa.

ISO_C_BINDING can be thought of as a set of voluntarily adopted set of rules. You follow the rules, and the Fortran compiler takes care of making your code work properly with objects produced by the approved C-compiler. Therefore, ERROR is appropriate when the Fortran compiler can detect code that does not conform to the rules. Using WARNING instead would be somewhat like brushing dirt under the carpet. With code that is in violation, especially with CHARACTER(len=) arguments, runtime errors are almost guaranteed.
0 Kudos
lklawrie
Beginner
901 Views
That's fine -- why wasn't it flagged at all in earlier (V11.1) versions of the compiler?

0 Kudos
TimP
Honored Contributor III
901 Views
Various possibilities (I don't know the specific reason). Maybe someone pointed out that the compiler is required to diagnose violations of the standard, at least when appropriate options are set. This would not be the first time that requirement is met by turning the non-conforming code into an error. Leaving an inadvertent extension in place would require assurance that it doesn't permit undiagnosed failure, as well as making it whine when -stand is set.
0 Kudos
Steven_L_Intel1
Employee
901 Views
We are always improving the diagnnostic capabilities of the compiler. This was a case we did not detect before.
0 Kudos
kferrio
Beginner
901 Views
We are always improving the diagnnostic capabilities of the compiler. This was a case we did not detect before.


And this is very much appreciated here, for all the usual reasons. Theeffort Intel has invested and continues to devote to both ensuring and documenting compliance with published standardsa key consideration in our adoption and continued use ofIVF.

0 Kudos
Reply