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

I think we can do this but could you post a short sample of code that will not compile under FTN95.

This generates: ERROR DTD_MOD.FOR 9: 32: Statement not recognised

!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]

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

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

I was hoping for the text of a small file that will compile under FTN95 when the IMPORT statement is commented out.

Aah, but that wasn't what you asked for! 😃 try this

!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

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 [u:392e4000cf]never[/u:392e4000cf] 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:

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:

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.

Back to you Kenny. I need a working sample where Intel requires IMPORT and FTN95 compiles OK when IMPORT is commented out.

ok, try this:

!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

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).

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.

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.

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

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

/VPARAM FTN95 1 /FPP /CFPP

while including the following in you code:

PROGRAM p
#ifdef FTN95
 USE m
#else
 IMPORT
#endif
END PROGRAM p

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.

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).

The C pre-processor should work fine with both compilers.

Kenny

/CFPP should work with FTN95 to provide C-style conditional compilation.

However, I will see if I can provide an interim fix later today so that IMPORT will be tolerated when using /F2K.

The only drawback is that FTN95 is currently 'locked' for the next full release so the fix would just be off my machine and there will be a 'regression' in FTN95 when you come to download the next full release.

great! will you be able to do a 'post release from your machine' when the time comes?

K

Yes, if necessary but I am assuming that there will be no other changes. So the only problem will be that the version number will be out of order. I am guessing that it will be 6.36.x when it should probably be 7.01.

Kenny

Here is an FTN95 beta for you to try...

http://www.silverfrost.com/beta/ftn95_636.zip