From Linux (ifort) to Windows (IVF+MVS)

[Maxim]

From Linux (ifort) to Windows (IVF+MVS)

---

I have a mixing (fortran main and c static lib) project. I have no problem for Linux. But I need to compile this project for Windows. Im trying to use Intel Visual Fortran for MVS 2010 (Windows 7 (64 Pro)).

I selected the next options:

Fortran/Preprocessor/Preprocessor Source File: Yes(/fpp)

Fortran/Compatibility/Enable F77 Run-time Compatibility: Yes(/f77rtl)

Fortran/Compatibility/Use F77 Integer Constants: Yes(/inconstant)

Fortran/ Diagnostics /Check Routine Interface/: No

For this options compile give me:

remark #5169: Misplaced conditional compilation directive or nesting too deep

error #6437: A subroutine or function is calling itself recursively.

If I setup the last item to

Fortran/ Diagnostics /Check Routine Interface/: ->Yes

there are additional errors:

error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.

error #7983: The storage extent of the dummy argument exceeds that of the actual argument.

For Linux I use both gfortran and ifort and all ok!

What should I change for Windows?

Thanks!!!

[Steven_L_Intel1 · Accepted solution]

So simple when I have the forest instead of individual leaves.

You have two problems, both of them on the C side.

The conditional code in sources such as memalloc.c and creapdb.c has a part like this:

#elif defined(PC)
#define creapdb (_stdcall CREAPDB)

It is evident that the writer of this code assumed that you would be using CVF or perhaps Microsoft Fortran PowerStation, hence the _stdcall. Take that out so that the line reads:

#define creapdb (CREAPDB)

The second problem is that the PC preprocessor variable is not defined for this project. Add it under C/C++ > Preprocessor > Preprocessor definitions.

Or do what you did in memalloc.c and just add the appropriate define directly (remove the _stdcall there,) If you fix this in both of those sources, and then build, it will succeed.

[Maxim]

Thanks Steve!!!!

But what should I add to C/C++ > Preprocessor > Preprocessor definitions ?
If I setup Fortran/ Diagnostics /Check Routine Interface/: Yes. I receive erro:

encalc4.f(140): error #6633: The type of the actual argument differs from the type of the dummy argument. [ERGC]

But for Linux all is OK! I tested program for Linux many time for various input. How is it possible?

[Steven_L_Intel1]

You would add:

;PC

to the end of the list for preprocessor variables.

On Linux, did you enable -warn interface? Probably not.

Here's the various coding errors this reveals:

In routine msrf you call ddtime passing the variable tary as an argument. tary is not declared (oops!) so it is implicitly a REAL scalar. ddtime is looking for an array of two REALs. It is an error to pass a scalar variable to an array, and especially bad in this case becauae ddtime is going to write two REALs when you pass only one, so whatever is in the location just after tary is going to be corrupted. Not good.

I note that tary is not used elsewhere in this routine so I am not sure what is intended here. You need to fix this.

Then there are three errors of the form:

error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [VINDX]

This is also in msrf. vindx is declared as an integer dimensioned (1) and it is used in calls to fxlh where the corresponding argument is declared as dimension (900000). This is also an error because if vxtri is assigned to past element 1, it could corrupt storage. Not good.

Now I know that back in the Fortran 66 days, people would declare dummy argument arrays as (1) to allow any size to pass. In Fortran 77, this would be an assumed-size array or dimension (*). But in msrf, vindx is not a dummy argument so this does not apply.

But wait... msrf includes a file called pointers.h which declares a bunch of things using the "integer pointer" extension (more generally called Cray pointers, though Cray doesn't like that term). There, vindx is declared as a "pointee", so the intention is for vindx to be assumed-size. The fix for that is to change (1) to (*) in the declaration of vindx in msrf. (A note - I consider it bad form to split the declarations like this as it can lead to misunderstandings.)

[Maxim]

Thanks you very much!

I will try to examine.