fp-model and other arguments

[ereisch]

I'm compiling a large program with the new 15.0.2 compiler, where we previously used 12.0.4.  Since we need to ensure our results are identical with the optimized and non-optimized version, we previously used the following compile arguments:

-extend-source 132 -assume nounderscore -assume nobscc -align dcommons -static-libgcc -zero -fp-port -c -fpe0 -ftz -prec-div -fp-stack-check -ccdefault fortran -traceback -fp-model precise

...when compiling the non-optimized (debug) version, we added the following: -g -debug full -debug-parameters -check bounds -O0

...and added in -O1 or -O2 for the nodebug/optimized version.  All was well in the world, and our results matched perfectly between both executables.  However, now that we're moving on to version 15, this is not so much the case anymore.  We're matching with the majority of our results, however some executions that involve multiple inter-communicating processes are no longer matching.  Our first hiccup was we had to change the "-fp-model precise" argument to "-fp-model source", according to the following warning:

"ifort: command line warning #10212: -fp-model precise evaluates in source precision with Fortran."

Sorry, but I'm having an extremely difficult time digesting that error message.  Upon examination of the manpage, it states that option fp-model precise is converted to fp-model source, however, just a few lines higher up in the manual it outlines that "precise" and "source" appear to do two completely different things.  Is "precise" also setting "source"?  It also seems to suggest you can select multiple options from the three groups listed, but doesn't say how.  "-fp-model precise,source" throws an error, "-fp-model precise -fp-model source" issues the same warning above, implying it is being ignored.

FWIW, here are the flags we're trying to use with 15.0.2:

-extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -c -fpe0 -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -fimf-arch-consistency=true -fimf-precision=high -no-fma -fp-model source -prec-div -fp-port -fp-speculation=strict -prec-sqrt -fltconsistency

...and the same debug flags as above.

Thanks in advance to any insight anyone has to offer.

[Steven_L_Intel1]

Ignore the message - we're doing away with that in the next version. In Intel C++, precise and source are different, but in Fortran they are the same.

Let me suggest that your quest to get absolutely identical results with a compiler version change (three versions!) is likely to be unsuccessful. See the attached presentation.443546

[ereisch]

Thanks, Steve.  Actually, we're not trying to match the results from 12.0.4 to 15.0.2 -- I don't enjoy self-flagellation.  We're just trying to get optimized and non-optimized results from one compiler version (15.0.2) to match.  "Similar" results to 12.0.4 is our version-to-version metric.  The core issue is if we have a strange condition appear in our code when running a large job (in optimized mode), we want to be able to go back and reproduce that result in the debug version so we can figure out what's going on.  Due to the butterfly effect of our code, numerical differences early on could prevent the strange condition from even appearing at all in the debug version, despite all the inputs being the same.

I'll read over that presentation, thanks.

[Steven_L_Intel1]

Even optimized vs. non-optimized you're very likely to have some numerical differences. The presentation suggests some ways you can minimize these.

[TimP]

If you're concerned about effects of data alignment, the option of recent compilers: '-align array32byte'  may be useful, although your choices of -fp-model should have disabled optimizations where that would affect numerics (at least if you compile for intel64).

I don't know whether ifort would recognize the fltconsistency option the way you spelled it, but I would hope that fp-model options would take precedence anyway. fp-port also is an obsolete option, as the recent compilers should not use x87 code with the options you gave.

If your results are affected by -zero, it would be better to identify and correct any undefined (uninitialized) data which may be responsible.

If there is any way fpe0 can improve numerical consistency, I'd like to be educated about it.  If it's a question of getting the ieee_fpe_flags setting, it seems you may need -fp-model strict,

[ereisch]

The fpe0 flag is not for numerical consistency, it's so we intentionally throw an error when we underflow or overflow.  We prefer to know the locations in code where this happens, because it usually is indiciative of an error.  Locations that are known to gradually underflow are trapped in code before underflowing.

Thanks for the tips.