| View previous topic :: View next topic |
| Author |
Message |
KennyT
Joined: 02 Aug 2005
Posts: 318
|
 Posted: Mon Aug 19, 2013 12:38 pm Post subject: Fortran 2003 extensions |
 |
|
We are being reluctantly forced into producing a version of our apps built on Intel Visual Fortran and its handling of Modules is "different", such that an "IMPORT" statement (apparently an f2003 extension) is needed in various places, which is unnecessary in FTN95...
Is there any way to have the FTN95 compiler ignore any "IMPORT" statements so we can minimise the differences between our source files?
K |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Aug 19, 2013 4:10 pm Post subject: |
|
|
| I think we can do this but could you post a short sample of code that will not compile under FTN95. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Mon Aug 19, 2013 4:37 pm Post subject: |
|
|
This generates:
ERROR DTD_MOD.FOR 9: 32: Statement not recognised
| Code: |
!ftn95$free
MODULE XT_MOD
USE D_TYPES
INTERFACE
SUBROUTINE XT_TreeNew (XROOT, XTR)
IMPORT
TYPE (GVEC), POINTER :: XROOT, XTR
END SUBROUTINE
END INTERFACE
END MODULE XT_MOD
|
K[/code] |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Mon Aug 19, 2013 5:20 pm Post subject: |
|
|
It seems that IMPORT (with or without an import-name list) simply makes variables available to an INTERFACE, viz:
ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf
| Quote: | 3.10 The IMPORT statement
In Fortran 95, interface bodies ignore their environment, that is, nothing from the host is accessible. For example, a type that is defined in a module is not accessible in an interface body within the module. The IMPORT statement has therefore been introduced. It has the syntax
IMPORT :: new_type, compute
and is allowed only in an interface body. Without an import-name list, it specifies that all entities in the host scoping unit are accessible by host association. With a list, those named are accessible. |
One can quite see, therefore, that code that conformed to 2003 would not work under 95, but not vice versa.
Eddie |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Aug 19, 2013 5:57 pm Post subject: |
|
|
| I was hoping for the text of a small file that will compile under FTN95 when the IMPORT statement is commented out. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Mon Aug 19, 2013 6:29 pm Post subject: |
|
|
Aah, but that wasn't what you asked for!  try this
| Code: | !ftn95$free
MODULE X_UNITS
INTERFACE
SUBROUTINE X_SIConvV (X, ISER, IOLD, INEW)
! IMPORT
REAL :: X(:)
END SUBROUTINE
END INTERFACE
END MODULE X_UNITS
|
K |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Mon Aug 19, 2013 7:52 pm Post subject: |
|
|
There are no circumstances where correctly written Fortran 95 code would not compile with a Fortran 2003 compiler. I regularly use the Intel compiler and IMPORT is never needed.
IMPORT was added to Fortran 2003 to allow an interface block to import definitions from the surrounding environment.
With Fortran 95 you need to repeat the definition in the interface block, for example:
| Code: |
use mmm_mod ! definitions from a module
interface
subroutine xxx ! whatever
use mmm_mod ! repeat to get definitions from module for xxx scope
end subroutine xxx
subroutine yyy ! whatever
use mmm_mod ! repeat to get definitions from module for yyy scope
end subroutine yyy
end interface
|
With Fortran 2003 you can write this like:
| Code: |
use mmm_mod ! definitions from a module
interface
subroutine xxx ! whatever
import ! Import everything from surrounding scope
end subroutine xxx
subroutine yyy ! whatever
import ! Import everything from surrounding scope
end subroutine yyy
end interface
|
If the code is working in Silverfrost's FTN95 then perhaps this compiler imports by default (I haven't checked). This is therefore an extension to the Fortran 95 standard or a bug.
I would urge caution with just getting the compiler to ignore IMPORT as a user may think that the lack of an error message means IMPORT is implemented when it is not.
KennyT's example code also compiles with the Intel compiler when the IMPORT statement is commented out, so it isn't a good enough example to illustrate when IMPORT might be used.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Last edited by davidb on Tue Aug 20, 2013 8:43 am; edited 1 time in total |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Aug 19, 2013 8:39 pm Post subject: |
|
|
| Back to you Kenny. I need a working sample where Intel requires IMPORT and FTN95 compiles OK when IMPORT is commented out. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Mon Aug 19, 2013 8:44 pm Post subject: |
|
|
ok, try this:
| Code: |
!ftn95$free
MODULE X_UNITS
TYPE RUNIT
SEQUENCE
INTEGER :: IUN, ISER
CHARACTER*16 :: CU
END TYPE RUNIT
INTERFACE
SUBROUTINE X_SIConvV (X, ISER, IOLD, INEW)
! IMPORT
type (RUNIT) :: X(:)
END SUBROUTINE
END INTERFACE
END MODULE X_UNITS
|
without the IMPORT, FTN95 is happy but Intel says:
x_units.for(15): error #6457: This derived type name has not been declared. [RUNIT]
type (RUNIT) :: X(: )
--------^
With the IMPORT, Intel is happy but FTN95 says:
ERROR C:\wlib\x_units.FOR 14: 32: Statement not recognised
K |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Aug 20, 2013 7:52 am Post subject: |
|
|
We will take a look at this.
1. The current FTN95 behaviour appears to be an extension of the Fortran standard.
2. We should aim to get FTN95 to accept IMPORT provided /F2K is used.
3. FTN95 should flag an error when /ISO is used without /F2K (and IMPORT is not included).
In the mean time the simplest work-around might be to use Intel conditional compilation (if there is such a thing). |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Tue Aug 20, 2013 8:30 am Post subject: |
|
|
Paul,
Your suggestions would be a reasonable way to go.
KennyT,
The new code is a much better example of the problem.
My workaround is just to repeat the definition of the SEQUENCE TYPE like this.
| Code: |
MODULE X_UNITS
TYPE RUNIT
SEQUENCE
INTEGER :: IUN, ISER
CHARACTER*16 :: CU
END TYPE RUNIT
INTERFACE
SUBROUTINE X_SIConvV (X, ISER, IOLD, INEW)
TYPE RUNIT
SEQUENCE
INTEGER :: IUN, ISER
CHARACTER*16 :: CU
END TYPE RUNIT
TYPE (RUNIT) :: X(:)
END SUBROUTINE
END INTERFACE
END MODULE X_UNITS
|
This should help while you are waiting for Paul to implement the new functionality.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Tue Aug 20, 2013 9:30 am Post subject: |
|
|
thanks, Paul/David.
David, while your suggestion works for this simple case, the amount of work required to implement and maintain it (when one "type" definition changes, instead of changing one line, we'd have to change dozens, leading to inevitable "typos"!) - so, provided Paul can implement his suggestion in a reasonable timescale, i think i'd prefer to wait!
K |
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 299
|
| Posted: Tue Aug 20, 2013 3:39 pm Post subject: |
|
|
Could you use a conditional compilation in this case? I've not studied the examples above in any detail, but I use conditional compilations quite frequently to handle different compilers' idiosyncracies. For example, try setting a parameter such as FTN95, and compiling with
| Code: | | /VPARAM FTN95 1 /FPP /CFPP |
while including the following in you code:
| Code: | PROGRAM p
#ifdef FTN95
USE m
#else
IMPORT
#endif
END PROGRAM p |
|
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Tue Aug 20, 2013 3:53 pm Post subject: |
|
|
if the source code syntax for conditional compilation was the same, then we could, sure. But i don't think the two compilers use the same method (e.g. FTN95 uses "CIF", not sure what IVF uses) - unless davidb knows better...
K
edit: it may work. IVF has an fpp switch (with a -D to define a parameter on the command line), which looks to use a similar syntax to the "VPARAM" line that you supplied. i'll try it, thanks. |
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 299
|
| Posted: Tue Aug 20, 2013 5:08 pm Post subject: |
|
|
| You probably want to avoid CIF etc for the reasons you state, but you should be able to use the C-style conditional statements such as those included in the example. I've not had any problems getting that to work on a range of compilers (nagfor, ifort, pgf95, gfortran). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
