migrate project CVF6.6c to IVF

[Renaud_Egal]

Hey folks !

I have a working project on Compaq visual fortran (written a couple years back now), but I'd like to migrate it to IVF to work on it.

Problem, I have a few compatibility problems I would need help on.

First thing first, this annoying error 6796 on pointers

R:\r.egal\Projets en cours\Programmes\Prosec3D\Test Intel\Prosec3D\Source1.f90(6): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [MAILLE]

The corresponding code (simplified) would be 

	subroutine case_x(maille)
		integer, intent(inout) :: maille
		integer, pointer :: pt_P
!-----------------------------------
		nullify(pt_P)
		pt_P=>maille
	end subroutine case_x

Why do I have this error when it works just fine in older versions ?

Is there an option in the project properties I'd have to check ?

Please advise

Cheers

Renaud

[mecej4]

The language rules are pretty clear on this issue, and you are being protected from potentially serious bugs by the compiler's refusal to accept the code. To me,  CVF 6.6C says:

bsub.f90(6) : Error: The variable must have the TARGET attribute or be a subobject of an object with
 the TARGET attribute, or it must have the POINTER attribute.   [MAILLE]
                pt_P=>maille
----------------------^

The CVF help also says "If an object does not have the TARGET attribute or has not been allocated (using an ALLOCATE statement), no part of it can be accessed by a pointer."

Which compiler options did you use (with CVF) to make the error message disappear?

[Renaud_Egal]

That is a code that was compiled long time ago, I don't know what are the options used to make "this error disappear". The only thing I know is that I was running CVF 6.6.0 and I was getting this error, so I upgraded to 6.6c and then it was working fine.

Here are the details of the options, but I can't analyze them

# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 1
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE F90 /check:bounds /compile_only /dbglibs /debug:full /nologo /traceback /warn:argument_checking /warn:nofileopt
# ADD F90 /browser /check:bounds /compile_only /cxml /dbglibs /debug:full /imsl /include:"Debug/" /include:"Sources/Include/" /nologo /traceback /warn:argument_checking /warn:declarations /warn:nofileopt /warn:unused /winapp /DARCH=1
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /FR /YX /FD /GZ /c
# ADD BASE RSC /l 0x40c /d "_DEBUG"
# ADD RSC /l 0x40c /i "umf.lib" /d "_DEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib /nologo /subsystem:console /incremental:no /debug /machine:I386 /pdbtype:sept
# ADD LINK32 umf.lib /nologo /subsystem:console /profile /debug /machine:I386

On the other hand, I can't figure out what is the version of the compiler installed with this version. Where do I find it ?

[Steven_L_Intel1]

As mecej4 says, your program is incorrect and the compiler is right to give you an error. It may be that the CVF version you used had a bug where it didn't catch the error - in the 10 years since CVF we've added a lot of error checking to the compiler.

This particular error is not one affected by compiler options and it is somewhat surprising to me that you didn't see an error from CVF about it.

[Renaud_Egal]

I can assure you that it compiles just fine on CVF.

So then does that suffice if I add the "TARGET" attribute to every occurence ?

Another way to fix that ?

[Steven_L_Intel1]

It would help if we understood what your actual program was trying to do. I'll note that if you add the TARGET attribute to the dummy argument that this triggers the standard's requirement that an explicit interface for the procedure be visible to the caller.

[Renaud_Egal]

What I want to do is re-use the program, without re-writing it !

What I'm trying to do with the intent/pointer/target thing is shown in the code sample below. I did not put the whole code cause it's really long and complex. But the main idea's here, ie passing a user object as an argument for accessing it via pointers (for further treatment)

program main 
    use mod
    implicit none
    type(a_arg) :: arg
    !initializes arg values
    arg%x = 0
    arg%y = 10
    arg%z = 20
    
    !call to do something on the object arg
    call do_something(arg)
        
end program main

module mod
    implicit none
    !defines a user-object
    type a_arg
        !with multiple attributes
        integer :: x, y, z
    end type
    
    contains
    
    subroutine do_something(arg)
		type(a_arg), intent(inout), target :: arg
		type(a_arg), pointer :: pt_P
        integer, pointer :: pt_a
        
		nullify(pt_P)
        !sets pointers for further use
		pt_P=>arg
        pt_a=>arg%x
        print*, pt_p
        print*, pt_a
        pause
    end subroutine do_something
    
    
end module

I hope tha'ts more understandable. The problem is that I can't re-write everything since that is a huge amount of code, result of more or less 3 years of study.

And Steve, what do you mean by "explicit interface for the procedure be visible to the caller" ?

[Steven_L_Intel1]

Ok. Yes, you need to add TARGET if you're going to use pointer assignment to something that isn't itself a pointer. As for explicit interface, since your procedures are in a module, you're covered there. For background, see  here.

[Paul_Curtis]

One more thing to think about when migrating from CVF to IVF -- CVF implemented SAVE (subroutine variable values retained between calls) by default, where IVF does not, and programs which implicitly depend on this feature may behave very very strangely when it goes missing.  You may need to add the SAVE attribute to your routines, or to specific variables.

[FortranFan]

Paul Curtis wrote:

One more thing to think about when migrating from CVF to IVF -- CVF implemented SAVE (subroutine variable values retained between calls) by default, where IVF does not, and programs which implicitly depend on this feature may behave very very strangely when it goes missing.  You may need to add the SAVE attribute to your routines, or to specific variables.

Or use an Intel Fortran compiler switch of /Qsave for all relevant code.  If one is using Visual Studio, one can set it under Project Properties -> Fortran -> Data -> Local Variable Storage.

[Renaud_Egal]

Thanks all, I'll do that for now. And I''ll take care of Qsave option also.

If I'm not mistaken, I should also set floating point model to "Source" and floating point speculation to "Strict". Things I found around the web concerning project migration.

SOme other problem I'm having is described below, again concerning pointers. Some routines are having allocatable dummy arguments, when calling procedures have these arguments declared as "pointers". I guess that's normal the compiler gives me an error, but my problem is how do I have to handle correction ?

Error is the following

 error #7976: An allocatable dummy argument may only be argument associated with an allocatable actual argument. 

Code is something like that. I found notes of why it was written this way, still this problem of CVF version. The only way to pass NON-ALLOCATED allocatable arrays was by using POINTER in calling procedure.

module mod2
    implicit none
    contains
    subroutine call2    !the calling procedure
        integer, dimension(:), pointer :: listp !declared as pointer
        call called2(listp)
        print*, listp
        pause
        
        !dealloc is made here
        deallocate(listp)
    end subroutine call2

    subroutine called2(lista)   !the called procedure
        integer, dimension(:), allocatable :: lista !error if declared as allocatable
        !integer, dimension(:), pointer :: lista !no error if declared as pointer
        
        !allocation is made here
        allocate(lista(10))
    
        print*, lista
        pause
    
    end subroutine called2
end module mod2

My dilemma right now is knowing how to modify everything. Should I declare only ALLOCATABLE arrays ? only POINTERS ? My guess is that they're both completely equivalent for what I'm trying to do, but I'd like your advices on the subject.

Thank you all very much for your help, it's been very helpful already !

[Steven_L_Intel1]

You can't mix allocatable and pointer. Unless you are using pointer assignment, =>, use allocatable everywhere - not pointer.

I would not recommend the floating point model changes you made on a general basis. If you insist on absolute bit-for-bit sameness, then those options may help but will seriously hurt performance (and may not guarantee identical results anyway.)

[Renaud_Egal]

Thanks for the tip Steve. I modified every occurence of pointer/allocatable mix to pure allocatable. That part seems to compile great now.

But as we say in France "on train may hide another", so now I'm getting these, using different compilers

• When I compile using Compiler XE 14.0.4.237[IA-32]

Error	1	 error #10037: could not find 'link'	Link	

• When I compile using Compiler XE 12.1.4.325[IA-32]

Error	1	 fatal error LNK1104: cannot open file 'dfor.lib'	LINK	

Let's mention I included in project folder the external library "UMF.lib" that I got from the old CVF project. I don't know if that's the cause, but it may (or not) help finding the cause.

[mecej4]

If you try to mix libraries and object files produced by CVF with those produced by Ifort, you are going to have problems. Even if you succeed in finding all the missing files (such as DFOR.lib) and place them appropriately, the resulting program may fail at the link or execution stage.

It would probably be best for you to create a clean, new project with only the source files copied over from the old project. But, given the dependence on UMF.lib, which in turn may depend on DFOR.lib, you should expect considerable trouble getting things to work.

[Steven_L_Intel1]

Just to be clear - the latest errors you have are at the link step, not compile. The 14.0 error indicates that Visual Studio isn't correctly configured to find the linker (and perhaps other Microsoft tools.) mecej4 correctly points out that you are linking in objects or libraries built with CVF, and that simply won't work. You need to recompile all Fortran sources.

[Renaud_Egal]

Yeah, I get that they're linking errors. It is not correctly configured, i can understand that. But I tried to follow compiler configuration in options panel

Executables
$(IFortInstallDir)bin\ia32
$(VSInstallDir)Common7\IDE
$(VCInstallDir)BIN
$(VSInstallDir)Common7\Tools
$(VSInstallDir)Common7\Tools\bin
$(FrameworkDir)$(FrameworkVersion)
$(WindowsSdkDir)bin
$(PATH)

Includes
$(IFortInstallDir)compiler\include
$(IFortInstallDir)compiler\include\ia32
$(IFortInstallDir)mkl\include
$(VCInstallDir)atlmfc\include
$(VCInstallDir)include
$(WindowsSdkDir)include
$(FrameworkSDKDir)include
$(FNL_DIR)\IA32\include\dll 

Libraries
$(IFortInstallDir)compiler\lib\ia32
$(IFortInstallDir)mkl\lib\ia32
$(VCInstallDir)atlmfc\lib
$(VCInstallDir)lib
$(WindowsSdkDir)lib
$(FrameworkSDKDir)lib
$(FNL_DIR)\IA32\lib 

I don't understand why it wouldn't link properly.

On the other hand, using 12. : the old project I retrieved does only contain reference to a lib file, and does not contain any umf fortran source files. If I understand correctly your saying, I'd have to find UMF source files (what I am looking for exactly ?) and compile them using IVF. 

Again, thanks for your patience.

[Steven_L_Intel1]

Yes, you would have to recompile the UMF library. I have no idea what that is.

I have seen this issue with "cannot find link" before even when the setup looks correct, but it has been difficult to track down. Usually it has to do with Visual Studio not finding the WIndows SDK even though the definition seems correct.

[Renaud_Egal]

Finally, I got it to work with 12.1 compiler configuration. I found UMF library files (some sort of numerical solver routines calling blas libraries) and added them to the project. No major problem here, that's already a good point, since I get similar results as CVF (on the benchmark file I used)

However, I can't figure out how to configure  properly my 14.0 compiler, since it still crashes at link step. . I'll have to use this compiler sooner or later, so I might as well loof for the solution right now

1>warning #31001: The dll for reading and writing the pdb (for example, mspdb110.dll) could  not be found on your path. This is usually a configuration error. Compilation will continue using /Z7 instead of /Zi, but expect a similar error when you link your program.
1>Linking...
1>Link: error #10037: could not find 'link'

I found this topic on the subject, but how do I transpose that to my case ? Meaning Microsoft Visual Studio 2010 Shell. Is that even the same problem ? 

[mecej4]

From the information that you have provided, it can be concluded that the reason for your V14.0 compiler's failure to build the application has little to do with the nature of your program source, the compiler options used or the inclusion of UMF and other such libraries in the project.

I suspect that your V14.0 compiler package will fail to build even a simple Hello World program, because the installation is faulty and not functional. There is one check that you can do to provide more information on the faults. Open an Intel Parallel Studio 2013 SP1 (or something close to this) command window and compile a simple program such as

program sqr
integer :: i,j
do i=1,10
   j=i*i
   write(*,*)i,j
end do
end program

and post the error messages in a reply.

[Renaud_Egal]

mecej,

I don't know how to launch the operation you just described. Please give me a hint on that.

I'm only using VS through main IDE, that's the only thing I usually handle.  When I do that, I get the same message, probably because of a non functional installation.

[mecej4]

You do it from the IVF command prompt, not from Visual Studio. See the attached screenshot