Specifying ifort switches in Parallel Studio XE

[Ahmad_Falahatpisheh]

Hi All,

In command prompt it is easy to specify the switches of IFORT and make the exe file. But when it comes to debugging, it is easier to use the visual studio for Intel Fortran. How can I specify the following switches in Parallel Studio in VS2005?

ifort myprogram.f /4R8 /O3 /Qopenmp /link /stack:10000000

Thanks.

[Steven_L_Intel1]

In Visual Studio, you use project properties. The switches you have are equivalent to the following properties:

Fortran > Data > Default Real Kind > 8
Fortran > Optimization > Optimization Level > Maximize Speed plus Higher Level Optimizations
Fortran > Language > Process OpenMP Directives > Generate Parallel Code
Linker > System > Stack Reserve Size > 10000000

The compiler documentation lists the equivalent "IDE" setting for those command options that have equivalents. For those that do not, you can add them on the Command Line property page for either Fortran or Linker.

[Ahmad_Falahatpisheh]

Thanks Lionel. That perfectly answered my question. Unfortunately, after compiling my code I get the following error:

error #6633: The type of the actual argument differs from the type of the dummy argument.

I don't get this error when I compile it by the following switches in command prompt:
ifort myprogram.f /4R8 /O3 /Qopenmp /link /stack:10000000

I think the error is caused by the switches in Parallel Studio which are:
/O3 /Qopenmp /warn:none /warn:interfaces /real_size:64 /module:"Debug\" /object:"Debug\" /check:none /libs:static /threads /dbglibs /c

Actually I tried to make the switches in Studio the same as the one on command prompt but I couldn't. Is there anyway so that I specify the switches by myself and not by GUI?

Thanks.

[mecej4]

>I think the error is caused by the switches

That is an improper inference. If you have a mismatch between caller and callee as to the argument list, the mismatch is usually not detected at compile time. Without corresponding error-checking features, such mismatches may fail to be detected even at run time.

If you show us the subroutine argument list, the declarations of the arguments, and the corresponding attributes at the point of subroutine invocation, we could help you with the mismatch.

The report of an argument list mismatch by the compiler is something that you should not ignore unless you can prove that the report is erroneous or that the consequences are benign.

[Steven_L_Intel1]

If you create a VS project, the Fortran VS system adds some compiler options by default. For a Debug configuration, one of those is /gen-interface (Diagnostics > Check Routine Interfaces). This is not on by default at the command line. As mecej4 says, the compiler has detected an error in your program and you should fix it.

It is certainly possible to make the VS environment match what you have on the command line, but I would suggest that taking advantage of the extra diagnostics would be useful when debugging. You'll want a Release configuration when optimizing.

[Ahmad_Falahatpisheh]

The following is the line where I get the error and the error is on FV:
CALL GATHER(MSHIFT,FVLIN(1),FV(0,0,0),INDUVW(1))

Also, the following is the declaration line of the subroutine GATHER:
SUBROUTINE GATHER(NPOINTS,TOARRAY,FROMARRAY,INDEX)
DIMENSION toarray(npoints), index(npoints), fromarray(*)
DO n = 1, npoints
toarray(n) = fromarray(index(n))
END DO
RETURN
END

I would appreciate your help.

[Lorri_M_Intel]

How is FV declared?

I saw a user's program a couple of weeks ago that received a similar error, and the variable in question had been explicitly declared as REAL*4.

Because you're using the /real_size:64 any un-sized REAL is bumped to REAL*8.
In the subroutine GATHER, fromarray will be promoted to REAL*8. If you are passing a REAL*4 thatcould cause the error message.

-- Lorri

[TimP]

If you are using default variable typing (not a good idea), the compiler will complain about the conflict between mshift (default integer) and toarray(default real). Besides, if mshift is not an array, it will complain on account of the array vs. scalar being a violation of the standard, even though Intel platforms can handle it if npoints==1, or in the case where mpoints is equivalenced to an array element.
You really would need to look at more of the source code.