Difference between cmdl 'ifort' and use in Xcode? (use module)

[markus_haenchengmail]

I have some legacy Fortran code that compiles fine both via the commandline (ifort) and via Xcode. But in the version coming out of Xcode one variable gets set to NaN which essentially hangs the code. The same source code compiled with 'ifort -o nameofexecutable includedfiles main.f90', does not have this NaN.
The code uses modules and the 'use' command. Somewhere in the documentation for the Intel compiler, I read that this is not fully supported, or at least I would have to arrange the source files in the Groups & Files section in the correct order (which I had to, to get it compile alright).

I am still tracking down where the first instance of the NaN occurs, but are the some compiler settings (I used pretty much the default Xcode cmdl Project) which can cause such discrepencies?

11.0.59 and Xcode 3.1.2 on OS X 10.5.6 (Intel), Core 2 Duo,

[Ron_Green]

Quoting - markus.haenchengmail.com

I have some legacy Fortran code that compiles fine both via the commandline (ifort) and via Xcode. But in the version coming out of Xcode one variable gets set to NaN which essentially hangs the code. The same source code compiled with 'ifort -o nameofexecutable includedfiles main.f90', does not have this NaN.
The code uses modules and the 'use' command. Somewhere in the documentation for the Intel compiler, I read that this is not fully supported, or at least I would have to arrange the source files in the Groups & Files section in the correct order (which I had to, to get it compile alright).

I am still tracking down where the first instance of the NaN occurs, but are the some compiler settings (I used pretty much the default Xcode cmdl Project) which can cause such discrepencies?

11.0.59 and Xcode 3.1.2 on OS X 10.5.6 (Intel), Core 2 Duo,

The Debug configuration in Xcode uses -g -O0 for compile options.

Yes, the Xcode integration is a "feature preview" or better stated "technology demonstration" for Fortran. Intel C++ fully integrates, but it's much more difficult to make Xcode work with Fortran. Editing works, simple compilations. But module dependencies are not recognized so you will have to order your module building order manually.

Your command line: without explicitly setting -Ox, you get -O2 by default. Big difference, there is a LOT of optimizations going on with your command line build.

I'd recommend these compiler options to make sure there aren't any existing issues with the code. Use these options for compilation AND link from the command line:

ifort -g -O0 -traceback -check all -warn all -fp-stack-check -fpe0

and let's see if all the runtime checks catch something in the code that isn't quite right.

[markus_haenchengmail]

Quoting - Ronald Green (Intel)

The Debug configuration in Xcode uses -g -O0 for compile options.
Your command line: without explicitly setting -Ox, you get -O2 by default. Big difference, there is a LOT of optimizations going on with your command line build.
ifort -g -O0 -traceback -check all -warn all -fp-stack-check -fpe0

Thanks, I've now figured out that the difference was all user error. My code uses two 'cache' files which are re-created if they don't exist. But the check whether they exist is carried out only on one of them, if it exists the code assumes the second exists as well. And since the working directory for the Xcode project was not the same as that of the source code, my Xcode working directory ended up with only one of the cache files, whereas the 'working directory' for a commandline compilation did contain both cache files. In short my Xcode compilation was failing to open a file and as a consequence setting a value to zero, by which something else got divided much, much later in the code and produced NaN.

Funnily enough, compiling with 'ifort -o0' gives an error ('can't link with a main executable') whereas 'ifort -o' works fine. And compiling with Xcode also works fine (once I copied my cache file into the working directory).

[Kevin_D_Intel]

You did not show the complete command line that led to the error, but compilation with -o0 works fine. That names the resulting executable as 0 (i.e. zero). See below.

I expect there was just something about your particular usage that was not understood by the driver, and expect it was probably accidental usage and intended as -O0.

$ ifort -V -o0 hello.f90
Intel Fortran Compiler Professional for applications running on Intel 64, Version 11.0 Build 20090131 Package ID: m_cprof_p_11.0.059
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

Intel Fortran 11.0-1569
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
Library search paths:
/opt/intel/Compiler/11.0/059/lib
/usr/lib/i686-apple-darwin9/4.0.1/
/usr/lib/
/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64
/usr/lib/gcc/i686-apple-darwin9/4.0.1/
/usr/lib/i686-apple-darwin9/4.0.1
/usr/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/


$ ./0
Hello from zero!

Glad to hear you identified the root cause of the differences and are moving forward.

[markus_haenchengmail]

Quoting - Kevin Davis (Intel)

You did not show the complete command line that led to the error, but compilation with -o0 works fine. That names the resulting executable as 0 (i.e. zero). See below.

Ah yes, I was trying 'ifort -o0 mynameformyexecutable main.f90', not giving a name to my executable does indeed result in a successfull compilation and an '0' titled executable (or a.out for my more complex project with included files).

On my project, '-check all' and '-fpe0' both produce an executable that fails with a floating point exception error in one line of my code, and sure as fire, there is another divide-by-zero-NaN event. Thanks for leading me down that path.