- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's pretty old. Can you try a newer one? Which version is your Windows system using?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
That is, we fixed something in the Composer XE 2011 version that was broken in the older compiler (from 2009)
-- Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page