Porting from Silverfrost FTN95 - anyone been here before?

[Kenny_T_1]

Hi,

I'm evaluating IVF with a view to "changing horses" from Silverfrost's FTN95 compiler.  I've tried compiling a source file with module definitions but get "loads of errors" that I don't know how to fix.  Has anyone trod this path before and is prepared to get me kick-started by "fixing" the attached source file?

TIA

K

[Steven_L_Intel1]

The IMPORT goes "inside" each procedure declaration, just as a USE would in the real routine. Yes, you need one for each.

[Kenny_T_1]

OK, now...

what are the rules on CONTAINS?

This appears not to be allowed?

[fortran]

MODULE D_TYPES

...

INTERFACE

SUBROUTINE DT_CSCADflt (V, CDEF)
  IMPORT
  TYPE (CSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE
...

END INTERFACE


CONTAINS

SUBROUTINE DT_CSCADflt (V, CDEF)

 TYPE (CSCA)    :: V
 CHARACTER*(*)    :: CDEF

    V%V        =  CDEF
    V%DEF    =  CDEF
    V%SET    =  -1
    V%ICODE    =  0
    V%CODE    =  ' '
    V%CAT    =  ' '
    V%PROMPT    =  ' '
    V%DESC    =  ' '

END SUBROUTINE

...

END MODULE D_TYPES


[/fortran]

C:\intel_vs\Lib1\d_type.f90(2322): error #6645: The name of the module procedure conflicts with a name in the encompassing scoping unit.   [DT_CSCADFLT]

k

[TimP]

The prodedure under CONTAINS supplies the explicit interface, so the INTERFACE block is redundant, and the multiple definition is forbidden.

[Steven_L_Intel1]

Right - if you have a CONTAINed procedure it supplies its own interface. In general, the only time you need to write an interface block is if you are calling non-Fortran or are declaring a generic interface.

[Kenny_T_1]

So, to summarise:

functions can appear either in an INTERFACE block, or a CONTAINS block, but not both.

functions that are in an INTERFACE block each need an IMPORT statement if they use TYPES defined in the same source, or a USE within the MODULE block, but routines in the CONTAINS block don't need/mustn't have the IMPORT statement.

Have i got that right?

K

[Steven_L_Intel1]

Not really.

Functions can appear in INTERFACE and in CONTAINS. But you can't use both to describe the same function in a given program unit. The contained procedure is its own interface, so adding an INTERFACE for it is a duplicate definition prohibited by the language. In addition, an interface (other than a generic) declares an external procedure, which conflicts with the contained procedure.

You really need to read Domestic or Imported? as well as Doctor Fortran Gets Explicit - Again!  The former tells you all about IMPORT, the latter is on explict interfaces.

[Kenny_T_1]

Thanks Steve, i read the first link but not the second one yet.  I was referring to single source files, in comparison to the "rules" (such as they are!) in FTN95 which:

Allows a function in both an INTERFACE and CONTAINS blocks, provided they agree in their definition.

Doesn't need multiple IMPORT statements in order to understand TYPEs defined (or USEd) in the "parent" block of a MODULE.

i'm not sure what the standard says, i'm just highlighting the differences as I find them!  (mainly so I can find them again in the future!!!)

K

[Steven_L_Intel1]

The first thing is clearly an extension to the standard. There was discussion in the standards commitee to allow this but they eventually decided against it. It's also a bit inconsistent to do that since, as I noted, an interface defines an external procedure. Maybe what you're referring to is the ability to use a module with an interface block in an external (not contained) routine. That would make more sense, though is still non-standard.

The second item is also non-standard. It could be that the FTN95 developers did not understand this aspect of the standard (it happens to us from time to time as well), or they decided to be "friendly", though in my opinion such an extension hurts more than it helps. But are you sure about this? It's not an issue when you use these types in contained subroutines - it's only INTERFACE blocks where it's an issue.

[Kenny_T_1]

For your perusal, the attached compiles happily under FTN95.

K

[IanH]

Oh dear.  Well, all you'd need to do is wait a few years, and then add the MODULE keyword in as a prefix in all the subroutine and function statements in the interface block.  But I digress.

[Kenny_T_1]

Been away - but now i'm back!

Got an annoying thing happening...

"build" recompiles everything (as though i've selected re-build) - i'm guessing there's a setting somewhere that's changed...where should i be looking?

K

[IanH]

Check for circular dependencies between modules.

[Kenny_T_1]

ah!  could be.  We've had problems with that before.  is there a tool that would help to spot them?

K

[IanH]

Yes.  This thread has some sensible suggestions. 

(I wrote my own, in Fortran, a year or two ago, This was possibly one of the silliest things I have ever done, but I think I had fun.  You can have the source to it if you want, but unfortunately it doesn't compile with recent/current ifort.  That said, I have been on my very best behaviour over the last few months, doing all my chores, keeping my bedroom clean, always using IMPLICIT NONE, not fighting with my siblings or C programmers, etc,  so maybe, just maybe, I might get rewarded by the Intel compiler folk in September/October-ish.)

[Kenny_T_1]

Haha!  i daren't turn on IMPLICIT NONE - i'd be waiting a year for the error log to finish being produced!

perhaps your code will compile with FTN95!  I'm willing to try it, if a useful tool is the end result...

K

[IanH]

That compiler doesn't have sufficient support for F2003.

[Kenny_T_1]

ok.  it was just an idea...

onto more important matters....

to try to "get to first base" with my main project, i built all my module code into one "solution" and all my application code into another "solution", included the modules path in my compiler options for my main app and hit "build".  Apart from the annoyance of the cyclic dependencies, it all compiled, at least.

So, enboldened with success, i tried to split the main "solution" into 3 "projects", one small exe plus two DLLs.  I checked to see that the modules path was included in my compiler directive for all the projects but i now get errors when trying to compile the source files for one of my DLLs, the error code for which (7002) implies that it can't find my modules any more...

what might i have missed?

TIA

K

edit:  OK, maybe i had a trailing blank in my include path, i retyped it and now it's working...

[Kenny_T_1]

OK, so i've got a DLL that uses entry points in another DLL.  How do i make my first DLL linkage produce a .LIB for the second DLL to link against?

K

[Steven_L_Intel1]

When you link the first DLL, if it exports at least one symbol the linker will automatically create a .LIB. If there are no DLLEXPORT directives, then it won't.

[Kenny_T_1]

ok, where do i specify the DLLEXPORT list.  In FTN95, there's an EXPORTALL link command...

K

[Steven_L_Intel1]

The Microsoft linker doesn't have such an option. In each routine, add the line:

!DEC$ ATTRIBUTES DLLEXPORT :: routine-name

where routine-name is the name of the routine.