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

[IanH]

Give your filename a .f90 extension, and try again.  The Intel compiler assumes that .for and .f files are fixed form.

(Alternatively, explicitly tell the compiler that the file is free form by using the /free command line option, or pop the !DEC$ FREEFORM compiler directive in the source - I see a similar directive already in there for silverfrost.)

[Kenny_T_1]

thanks Ian, i'd already spotted that and have the /fr switch in my compile script.  Here's an example of what i'm left with:

d_type.for(100): error #6516: This attribute specification is not valid for a component definition statement.   [TARGET]
  TYPE (AXSC), TARGET   :: SCA(10)
---------------^

d_type.for(153): error #6249: This symbol has multiple TARGET statement/attribute declarations which is not allowed.   [SCA]
  TYPE (AXSC), TARGET   :: SCA(10)
---------------------------^

d_type.for(959): error #6027: All derived type fields within a sequenced type must be of a derived-type that is sequenced (R424.2).   [ZPS]
  TYPE (ZPSET), POINTER :: ZPS=>Null(), CZPS
---------------------------^

K

[Steven_L_Intel1]

If Silverfrost allowed TARGET in a TYPE declaration, that's either a bug or a pointless extension. TARGET is an attribute for variables. Just remove those TARGET attributes.

The third error is also valid - any components of a SEQUENCE type must themselves be SEQUENCE types. So add SEQUENCE to the declaration of type ZPSET.

I recommend renaming the file rather than use /fr.

[mecej4]

Your d-type.f90 file requires the source for a module, AUX_INT, which you forgot to provide. Given that your source file is rather long, I'll note that the lines that you showed (above, in-line) pertain to components of a derived type. Thus, you are attempting to specify TARGET as an attribute of individual components, which is what Steve wrote about.

[Kenny_T_1]

Steve, that's great, i'm getting close now.  just got this left:

d_type.for(8412): error #7835: Record fields or array elements or sections of pointers are not themselves pointers.   [ASSOCIATED]
            IF( ASSOCIATED(W(L)%AX(J)) ) CALL DT_RVECDel (W(L)%AX(J))

Here's the source snippet (error line indicated by *******s):

TYPE WXP
  INTEGER        :: JW, IZ, ITRCH, USE
  TYPE (IVEC), POINTER    :: IX(:)
  TYPE (RVEC), POINTER    :: AX(:)
  END TYPE WXP
.

.

SUBROUTINE DT_WReset (W)

  TYPE (WXP)    :: W(:)

    N    =  SIZE(W)
    DO L = N, 1, -1
     IF( ASSOCIATED(W(L)%AX) ) THEN
       NA    =  SIZE(W(L)%AX)
       DO J = NA, 1, -1
*****        IF( ASSOCIATED(W(L)%AX(J)) ) CALL DT_RVECDel (W(L)%AX(J))
       END DO

what's the fix for this? I'm assuming I either have to change the definition of AX to be something other than a pointer or change "associated" to something else - what's best?

Thanks for your help!

K

[mecej4]

Simply remove the superfluous and erroneous " IF( ASSOCIATED(W(L)%AX(J)) )". The source code seems to have been written with confusion between "pointer to array" and "array of pointers". 

[Kenny_T_1]

mecej4 wrote:

Simply remove the superfluous and erroneous " IF( ASSOCIATED(W(L)%AX(J)) )". The source code seems to have been written with confusion between "pointer to array" and "array of pointers". 

I have to say that this isn't my code originally, but if I understand the intention, removing the test will try to delete the memory whether it has been allocated or not, which will surely result in a runtime error, won't it?

Tks

K

PS, ...but not if the SIZE function is doing its job I guess!

PPS, i tried to upload that missing file but i keep getting errors when i do...

[mecej4]

Kenny T wrote:
 removing the test will try to delete the memory whether it has been allocated or not, which will surely result in a runtime error, won't it?

No, because the statements in the IF .. ENDIF construct will be skipped if W(L)%AX is not associated, and SIZE will not even be evaluated.

To attach a file, give it one of the approved endings and drag-drop into the Attachments area, or zip it and attach the zip file.

[Kenny_T_1]

trying again...ok, it worked this time.  i didn't do anything different (honest!)

K

[mecej4]

By adding the SEQUENCE attribute to a number of your user-defined types, and removing the  " IF( ASSOCIATED(W(L)%AX(J)) )" clauses as directed by the compiler, I was able to compile your two files with just warnings of misalignment and no errors.  That is neither here nor there if, as a result of adding the SEQUENCE attribute to them, your types are no longer compatible with the library that you are going to link your code with as to memory layout.

[Kenny_T_1]

thanks, mecej4 and Steve.  much appreciated!

K

[bmchenry]

One item to be sure you realize: Intel Fortran does not build .Net (dotNet) applications whereas Silverfrost does.

I prefer building INTEL win32/win64 dlls/executables however sometimes have to link/work with dotNet type environments/other programs so you'll need that in mind to keep things working on both. I use Silverfrost with Visual Studio 2008 and Intel with Visual Studio 2010/2012to avoid any cross pollination between the two compilers.

[Kenny_T_1]

Thanks for the heads up, we don't intend to do .net apps, life's complicated enough in win32!

K

[Kenny_T_1]

OK, another issue (which I knew would be a problem...)

FTN95 has a series of "intrinsic" CORE functions that allow addresses to be converted to values (the reverse of LOC), thus:

REAL A

INTEGER IAD

IAD=LOC(A)

A=FCORE4(IAD)

From a brief scan of the help files, i'm guessing that TRANSFER is the equivalent function, but i thought i'd ask here first before doing loads of editing!

TIA

K

PS.  Reading that page more thoroughly, i'm not so sure TRANSFER on it's own does what I want - do I need to combine it with %VAL?

[TimP]

%VAL was a legacy extension (not widely supported) which accomplished what would be done with the value attribute in iso_c_binding.  I think general speculation on how those ftn95 intrinsics relate to standard Fortran would be out of place here; did you try the "official" Salford translation of fcore4 or compare it with what a Cray pointer would do?

http://forums.silverfrost.com/viewtopic.php?t=2480

[Kenny_T_1]

Thanks for replying, but i don't follow.

that link says i should code up something in "c" - is that what you are recommending?

Also, i don't know what a "cray pointer" is, is it a dog that helps fresh water fishermen find their lobster pots :)?

K

[Steven_L_Intel1]

Neither TRANSFER nor %VAL will be of direct use here. TRANSFER simply moves bits from one argument to the other, and %VAL is usable only in the actual argument list of a non-intrinsic procedure call.

There are a couple of ways to do this, one that is non-standard but a bit easier, the other which is standard but more complex. But first I will point out a bit of danger in your use of INTEGER to declare something that holds an address - this won't work when building a 64-bit application.

There are several different approaches you could take, some standard, some extensions. The snippet of code you showed doesn't make a lot of sense, as you're effectively assigning A to A. So that I can advise you better, can you give a better example? Are you required to work with integer addresses or would use of Fortran standard pointers be acceptable? What is the context of this code?

[Kenny_T_1]

Hi Steve,

here's a simple example that, in FTN95 sets B=A:

  PROGRAM TEST
 
  REAL*4 A,B
  INTEGER*4 IAD
 
  A=2.4
  IAD=LOC(A)
  B=FCORE4(IAD)
 
  WRITE(*,*)"A,B=",A,B  
 
  END             

the context is that, for historical reasons, our code passes the location (IAD) between functions and the CORE routines retrieve the stored values.  Rewriting that main functional code in "another way" will be impractical...

K

[Steven_L_Intel1]

Ok. Here's the simplest conversion:

[fortran]
PROGRAM TEST

REAL*4 A,B
POINTER (IAD, B)

A = 2.4
IAD = LOC(A)
B = A

WRITE(*,*) "A,B",A,B

END
[/fortran]

The POINTER statement with parentheses is an "integer pointer" declaration, not to be confused with the Fortran standard POINTER feature. Inside the parentheses are two names - the first is an integer variable called "pointer" that can hold an address, and it is automatically declared as the right integer kind if not already declared. The second is called the "pointee". It is a variable of any type whose location is taken from whatever value is in its associated pointer. Referencing the pointee is the equivalent of using the FCORE function on the pointer, if that makes sense.

[Kenny_T_1]

ok, thanks, i'll see how implementable that is with our existing function calls.

K