Prepare code to go from 32-bit IFORT to 64-bit IFX

[sindizzy]

So I've read the porting guide and that seems to address only the compile switches. Is there a guide on best practices to prepare the actual code to go from 32-bit to 64-bit?

I've read on some of the posts that variables set with default type will be different between the two compilers. If so are there guidelines on how to prepare the code for eventual porting from 32 to 64 bit? Anything else I should start to look at?

Edit: I just remembered that some of the compile switches will take care of the defaults. So I guess I should be good...(I think) unless anyone has other suggestions.

AGP

[andrew_4619]

Well other than setting a 64 but configuration there are no other settings to worry about. Set up a project and compile it to see what errors you get. The only problems will be anything that holds a memory address, so any windows handle for example which neet to be 64 bit integer.

[sindizzy]

We do use QuickWin but only to show progress. Other than that we dont use anything Window related even shelling out other programs. All our processes are done through memory.

[sindizzy]

One thing I did  notice is that the 64-bit project properties are different than my 32-bit project. So I think either the prior developer -OR- I assumed they would be copied over. I will have to spend some time making sure all my options are the same in VS for 32-bit vs 64-bit.

[jimdempseyatthecove]

The problems one generally encounters relate to coding assumptions that happen to work in 32-bit but will fail in 64-bit.

For example, a Windows handle in 32-bit application is 32-bits and you may have gotten away with interchanging handle with integer. Same with pointers. If your 32-bit code did not use the (library module) user defined types (e.g. HANDLE, C_PTR, etc...), then expect your program to fail.

Most of these errors can be caught with /warn:interfaces

Jim Dempsey

[sindizzy]

Thanks Jim,

The code I inherited is for the most part F77 based so not a whole lot to do with window handles. Although we do use QuickWin for displaying progress. I'll take a look to see if that requires any modification.

Now pointers, the code seems to be made up of fairly straightforward calculation routines. No pointers from my initial review but I'll run through it again.

However, thanks for the  /warn:interfaces tip as right now its set to /warn:none

AGP

[sindizzy]

So I do have a couple of places i use windows handles like the one below. As you sated the result can be 32-bit or 64-bit depending on the OS that's running it. But having trouble finding a good example of how to define it as a HANDLE.

hwndChl = GETHWNDQQ(6) ! !this gets the windows handle for the child window. standard units are stdin=5, stdout=6, and stderr=0.

warning #6075: The data type of the actual argument does not match the definition. [HWNDCHL]

[jimdempseyatthecove]

I'd suggest you make a full run in Debug mode with all runtime diagnostics enabled.

If the runtime is too long, create a new project, based on Debug, call it DebugFast, then after a reasonable time of a test run, without errors, if you terminated the test before completion (taking too long), stop the run, and in the solution explorer, locate the source file that is contributing the most CPU time. Right-click on that file, select Properties, then change the optimization level to maximum speed. Repeat test.

If necessary, you can repeat adding file optimizations.

Once you shake out any/all runtime errors (if any), then you can use the Release build.

FWIW I generally have several (or more) configurations:

Debug

DebugFast

DebugFastOpenMP

Release

ReleaseOpenMp

For example, DebugFastOpenMP has the configuration default optimization as fastest, but with the source file under test/revision set to no optimizations (with or without runtime checks as the case may reqire).

Jim Dempsey

[jimdempseyatthecove]

subroutine foo
  use ifwinty
  implicit none
  integer(HANDLE) :: hSomething

ifwinty == Intel Fortran Windows Types

Jim Dempsey

[sindizzy · Accepted solution]

I don't think I've ever used that before but I'll look at the documentation

Thanks for the example!

[andrew_4619]

Of course if you are not really using  the windows API you could avoid reliance on  using proprietary Intel modules using standard portable Fortran.

    use, intrinsic :: ISO_C_BINDING, only: C_INTPTR_T
    integer(C_INTPTR_T) :: HhandleThing

[jimdempseyatthecove]

ifwinty, and some of the other Windows related modules define integer parameters (like that for HANDLE), while other Windows function arguments take TYPE. These will require

type(whatever) :: something

If you write your own interfaces, please consult the various .f90 files in the compiler installation folder for the function of interest .OR. a function taking similar arguments. Use that as a guide if you need to write your own interface.

If your interfaces are calling C functions, include the BIND(C) or BIND(C, NAME="TheNameYouWantHere")

Note, "pointer" in Fortran is not the same as "*" in C/C++.

Jim Dempsey