Porting from Silverfrost FTN95 - anyone been here before?

115 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Well, ifort still works, so I think i've reinstalled OK.  Is it an incompatibility between VS2012 and the VS2010 shell?

K

Something strange happening with ifort when i try to use it to link against a static library created by FTN95, even if i don't actually make a call into the library...

source

program main
  character*260 :: path
  path=" "
  write (*,*) "prepath="
!  call AW_GetEXEPath (PATH, IRET)
  write (*,*) "path=",iret, path
end 

if i compile with this command:

ifort new2.f90

new2.exe runs as expected.

But if i use:

ifort new2.f90 llib.lib

i get no output generated by new2.exe, regardless of whether i make the call to AW_GetEXEPath or leave it commented.  i'm obviously missing something fundamental...but what?

K

such as a DLL corresponding to the lib not  being on PATH

Citation :

TimP (Intel) a écrit :

such as a DLL corresponding to the lib not  being on PATH

it's something like that, the quoted LIB has a DLL which is linked against a whole stack of other DLLs (many of which don't have LIB files (because FTN95 doesn't need them).  Anyway, i've got a simple example working, time for some binary chopping!

thanks

K

ok, it appears that, in order to use FTN95 DLLs, there mustn't be any undefined externals in them, even if those routines are never called at run time?  Looks like it's time to do some tidying up!

K

Help!

My Hard disc has failed, so i've bunged an old one in my laptop and downloaded the installer again, but when i come to run it, i get these warnings (which i don't remember seeing before?).  Advice please...

Intel(R) Parallel Studio XE 2013 installation can continue, but take note
  The Intel(R) Parallel Studio XE 2013 requires that a Microsoft* development product be installed.  Refer to the Release Notes for a list of the required Microsoft* development tools. 
Installation can continue; however, you will have to configure Compiler scripts for command line build environment by hand if you want to use them. Refer to documentation for instructions how to do it.
  Microsoft .NET Framework* 4.0 is not installed on this system and is required in order to install Visual Studio 2010 Shell.
Installation can continue but you will not be able to install Visual Studio 2010 Shell.
 Please refer to the Intel Visual Fortran Composer XE Release Notes for instructions on how to install the missing Microsoft component.
  The following components can not be installed: 
          - Integration(s) in Microsoft Visual Studio* 
Installation can continue; however, these components will not be installed because they require that a supported Microsoft* development tools be installed. Refer to the Release Notes for a list of the required Microsoft* development tools.
 

what do i need to install first?

K

Did you have Visual studio already before? There are 2 downloads for ifort/windows, the larger one includes the visual; studio shell and install it at the same time. It look like you have the one without the shell...

ok, i had to install dotnet4, and the separate Fortran compiler first (even though the main installer includes it?)

so i'm back up and running, thanks.

K

But, Steve, your exe file in Winapp1 project has tripped over my virus checker?

K

Fichiers joints: 

Fichier attachéTaille
Télécharger winapp-virus.png44.53 Ko

Citation :

Kenny T. a écrit :

ok, it appears that, in order to use FTN95 DLLs, there mustn't be any undefined externals in them, even if those routines are never called at run time?  Looks like it's time to do some tidying up!

K

OK, so it wasn't unresolved externals that was the problem...

I had to binary chop my FTN95 DLL link scripts to isolate the one source file that was causing the grief, then binary chop commenting the source code for that file to isolate the one routine that caused the issue, and you know what it was?

An extra END statement that hadn't been "cut" when a routine was moved to another source file, so the preceding routine had two of them!  So that stopped IVF in its tracks, even though the offending routine wasn't called (in fact, nothing in that source file was actually called but it still caused a problem...)

Time for a cuppa!

K

FWIW - a single END statement on its own is a valid main program.  I don't see or recall specific details of error messages etc that you've encountered, but duplicate main programs typically cause multiple definition problems or similar angst at the link stage.  In ifort's case I think the symbol in the object file that corresponds to the procedure that implements the main program is _MAIN__.

OK, getting into the syntax differences now...

Am I right in thinking that the following construct isn't supported by IVF?

WHILE (test) DO
.
END WHILE

and should be replaced by:

DO WHILE (test)
.
END DO

K

OK, going in leaps and bounds now :). But I have a n00b question about VS...

is it possible to have a "complete solution", containing the source for an EXE and DLLs and to build them all "in one go" or should I rather have separate solution files for each of my DLLs?... (I may be using the wrong terminology, so if more explanation/ clarification is needed, let me know).

K

Yes. A solution consists of one or more projects, so you can have projects that build the dlls and a project that builds the exe. You just need to ensure that you mark the project that builds the exe as depending on all of the other projects.

Les

Also, in cases where there is no logical dependency between a DLL and an EXE (perhaps they are independent outputs from the same source code) or where your solution involves multiple EXE's, the menu command Build > BuIld Solution does what it says, on good days.

Citation :

Kenny T. a écrit :

But, Steve, your exe file in Winapp1 project has tripped over my virus checker?

This is common with antivirus programs - a false positive on something it is not familiar with. Ignore it.

Steve - Intel Developer Support

ok, i've told Avira to ignore the exe, seems to be happy now!

now, back to the main fun and games...

The toolkit that i'm using works nicely, providing me with a "windows" application, from a "console" IVF main linked via an FTN95 DLL (!).  The only irritation is the appearance of the black console window - is there a way to stop it from appearing?  I'm not sure i want to delve into the mysteries of "winapp" quite yet as that seems to duplicate (and may interfere with) the operation of the toolkit that i'm using.

K

PS, a belated thanks to Ian and Les for their replies...

No - if you have a console application, you get the console. A "winapp" would avoid this. It should not be a problem as you're running a separate executable. Just strip out all of the code that deals with windows, leaving a WinMain function as the equivalent of the main program and have this call your DLL.

Steve - Intel Developer Support

thanks Steve, i think i'm missing a trick...

function WinMain()
      CALL REP
      
      winmain = 0
end      
    
subroutine REP

but i get a link error:

Error    4     error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup    LIBCMTD.lib(wincrt0.obj)    

Sorry to be a dunce!

K

Needs to look like this:

function WinMain (hCurrentInst, hPreviousInst, lpszCmdLine, nCmdShow)
!DEC$ ATTRIBUTES STDCALL,DECORATE,ALIAS:"WinMain" :: WinMain
use IFWIN
integer(SINT) :: WinMain
integer(HANDLE), intent(IN) :: hCurrentInst, hPreviousInst
integer(LPCSTR), intent(IN) :: lpszCmdLine
integer(SINT), intent(IN) :: nCmdShow
call REP
WinMain=0
end function WinMain

Steve - Intel Developer Support

perfick, thank you!

K

ok, so now to build my complete app using IVF...

For all our apps, we have a common set of modules - how do I refer to them?  I don't think i want to copy the module source files (and resulting MOD files) into each project folder.  Also, the order of the compilation of the modules is important, as some files USE modules defined in others.  How do i force the order of compilation?

K

What I usually recommend is that you create a static library project for your modules. Then make this a "dependent project" of the executable projects - this will automatically make the compiled modules and the library available to the executable project. Add the library project to the app "solution", right click on the executable project and select Dependencies. Check the box for the library project.

You do not force the order of compilation. If the module sources are part of the project, they will be compiled in the proper order. If you are using a subproject, then they'll all be compiled before the app project needs them.

Steve - Intel Developer Support

ok, thanks.  in an effort to play at "arne saknussemm" it should be noted that FTN95 uses a different KIND scheme.  See:

http://stackoverflow.com/questions/838310/fortran-90-kind-parameter

K

i'm having some issues with modules.  The .mod file is being generated in the "debug" folder, but i don't seem to be able to "USE" it?  i get errors such as:

C:\intel_vs\Lib1\x_units.f90(258): error #6457: This derived type name has not been declared.   [DSCA]

DSCA is declared here, in a different source file.

MODULE D_TYPES
...
 TYPE DSCA
  SEQUENCE
  REAL*8        :: V                    ! 0                               
  CHARACTER*32    :: STR                  ! 8
  TYPE (RUNIT)    :: VU                   ! 40, 44, 48                      
  INTEGER        :: SET, ICODE, PREC, US ! 64, 68, 72, 76
  CHARACTER*16    :: CAT, CODE               ! 80, 96
  CHARACTER*32    :: MASK                 ! 112
  REAL*8        :: MN, MX, DEF          ! 144, 152, 160
  CHARACTER*20    :: PROMPT               ! 168
  CHARACTER*40    :: DESC                    ! 188
  REAL            :: ERR                    ! 228
  
  END TYPE DSCA
...

and i'm using it, thus:

MODULE X_UNITS
  USE D_TYPES
...
INTERFACE
...
SUBROUTINE X_DateIAdd (D1, IM, D2)
  TYPE (DSCA)    :: D1, D2
  INTEGER        :: IM(:)
  END SUBROUTINE
...
END INTERFACE

my compiler command line (which i haven't edited) looks like this:

/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c

What else do I need to set?

K

Interface bodies for external subprograms (the SUBROUTINE X_DateIAdd... thing inside the X_UNITS module) do not, by default, inherit things from their host scope.  DSCA is known in the host scope because it has a use - there's no such USE in side the interface body so that name is not defined.

You can either add `USE D_TYPES` to the inside of that SUBROUTINE X_DateIAdd interface body, or if you want to play on the Fortran 2003 swings, you could add `IMPORT DSCA` to that interface body - this enables inheritance of that symbol from its host.

(Because the type is a sequence type, you could also repeat its entire definition, but that's a lot of typing.)

Your previous compiler needs a bit of a kick up the backside if it didn't complain about this.

Thanks Ian, that fixed that problem but i have a subtly different one as well!  (sorry, but hopefully the effort involved here will help others in the future!)

i have the following source, in a single file:

MODULE D_TYPES
...
TYPE CSCA
  SEQUENCE
  CHARACTER*40    :: V
  INTEGER        :: SET, ICODE
  CHARACTER*16    :: CAT, CODE
  CHARACTER*20    :: PROMPT
  CHARACTER*40    :: DESC
  CHARACTER*40    :: DEF
  END TYPE CSCA
...
INTERFACE
! ===========================================================================
SUBROUTINE DT_CSCADflt (V, CDEF)
  USE D_TYPES
  TYPE (CSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE
...
END INTERFACE

but i get the following errors

C:\intel_vs\Lib1\d_type.f90(1045): error #6928: The module-name on a USE statement in a program unit cannot be the name of any encompassing scoping unit.   [D_TYPES]
C:\intel_vs\Lib1\d_type.f90(1046): error #6457: This derived type name has not been declared.   [CSCA]

if i leave out the "USE D_TYPES" line, i still get the second error...

what's the fix?

K

If you stick to Fortran 95, the fix is to either move the type definition into a new module and then USE that module in both D_TYPES and the interface body, or (and this is only because the type is a sequence type) repeat the entire type definition inside the interface body. 

(If the type wasn't a sequence type, then you would need to go the separate module approach.)

If you advance to Fortran 2003, then you can use the statement IMPORT CSCA in place of the USE inside the interface body.

OK, if I understand correctly, i have to have separate MODULE source files for the TYPE definitions, INTERFACE block and CONTAINS block?  or can the INTERFACE and CONTAINS blocks stay together?

K

Kenny
The simplest solution is to add the IMPORT statement within the interafce block.
You may specify specific items(s) e.g. IMPORT :: CSCA
or
just have IMPORT on its own then "all of the accessible named entities in the host scoping unit are imported." (from the help).

Les

 

If you don't want to use the F2003 import statement that Les mentions, the F95 module arrangement looks something like:

MODULE some_name
  IMPLICIT NONE
  TYPE CSCA
    ...
  END TYPE CSCA
  ...
END MODULE some_name
MODULE D_TYPES
  USE some_name
  IMPLICIT NONE
  INTERFACE
    SUBROUTINE DT_CSCADflt(V, ...)
      USE some_name
      IMPLICIT NONE
      TYPE(CSCA) V
    END SUBROUTINE DT_CSCADflt
  END INTERFACE
  ...
END MODULE D_TYPES

The contains statement (in this case) is a structural part of the syntax of a module - it separates the specification part of a module from the procedures defined by the module.

For more information on this topic, see Domestic or Imported?

Steve - Intel Developer Support

ok, but...

I still have to have an "import" line for each function, thus?

INTERFACE
! ===========================================================================
import 
SUBROUTINE DT_CSCADflt (V, CDEF)
  TYPE (CSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE
import
SUBROUTINE DT_FSCADflt (V, CDEF)
  TYPE (FSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE

K

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

Steve - Intel Developer Support

OK, now...

what are the rules on CONTAINS?

This appears not to be allowed?

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

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

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

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.

Steve - Intel Developer Support

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

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.

Steve - Intel Developer Support

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

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.

Steve - Intel Developer Support

For your perusal, the attached compiles happily under FTN95.

K

Fichiers joints: 

Fichier attachéTaille
Télécharger d-type.for204.2 Ko

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.

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

Check for circular dependencies between modules.

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

K

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

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

That compiler doesn't have sufficient support for F2003.

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

Pages

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui