Understanding IEEE Floating Point vis a vis IVF 9.0.029

[Ben_W_]

This is not a bug report.

I am building floating-point intensive libraries with IVF 9.0.029 and Visual Studio 2005.

For simplicity, and so that we have a baseline for discussion, the scope of this post is limited to the LAPACK install test known as 'testieee'. I have attached the source for reference, which is freely available at www.netlib.org/lapack and bears the original copyright notice. Building LAPACK is not my ultimate goal, but it makes a point which will affect my code also.

When I build in Debug, 'testieee' indicates that floating point behavior is IEEE conformant. Cool.

When I build in Release, 'testieee' indicates that floating point is *not* IEEE conformant.

I have the 'Floating Point' options for IVF set identically for Release and Debug in Visual Studio. So I suspect the difference must be in the optimization (speed vs. compatibility) flags. I have not tracked down which one (yet), but I will.

Does anyone have a suggestion as to which compiler flag(s) are implicated? My interest is not so much in ensuring that some test 'passes' but rather that I understand the compiler flags. I'm hoping that using an example (LAPACK) that a lot of Fortran folks know will increase the odds of success.

Thanks,
Kyle

[TimP]

Setting -fp:precise, and (if running the 32-bit compiler) choosing one of the SSE2 options (-QxW, -QxN, -QxP, -QxT) should go a long way toward improving floating point numerical consistency. Does the documentation need improvement?

[Ben_W_]

Tim,

Thanks. The docs are actually quite good and constantly improving. That's something I really appreciate about IVF. This is all coming back to me like reality after a long vacation... I keep tellingmyself that someday I will actually read IEEE-754 and -854. Sure. Next time I'm on the beach. ;)

What I find is that +/-Inf and negative zero are always handled correctly (quite apart from the semantics of sgn) but NaN is handled correctly only for /Od but not for /On for any of n=1,2,3. Understandably, all optimizations sacrafice fp consistency right off the bat. And I completely forgot about the alphabet soup of -Qx options. My bad. Thanks for the friendly reminder.

Kyle

[Steven_L_Intel1]

Improvements to the default handling of NaN are coming in the future, but Tim's advice is sound. /fp:precise (or source) is your best bet if you need complete IEEE754 compliance regarding exceptional values and reassociation.

[drgfthomas]

I've read the docs. Perhaps I've missed it but what's the connection between fltconsistency (Default/Improved) in the VS 2003 IDE and /fp:****? and what happens if you mess with both?

[TimP]

I think the docs do need improvement there. Compiler team people have told us verbally that the old options are to be superseded by the -fp: options. According to my own experience, -fp:precise is similar to /fltconsistency, except that no promotion to double precision intermediates is engaged for SSE options.

[Steven_L_Intel1]

Do not use /fltconsistency or -mp. Use the appropriate /fp option.

[Ben_W_]

Steve,

Thanks as always for getting right to the point.

There is one aspect of /fpe that I definitely don't understand. This concerns the assertion that, "this option allows some control over floating-point exception handling for the main program at run-time." (emphasis added)

I believe there may be another place in the docs where floating point behavior is MAIN is singled out against other routines. The implication was that IEEE handling had to be global, not per-compilation unit. Is that right?

I had a notion to compile IEEE-sensitive routines (whose callers and callees are not IEEE-sensitive) with /fpe:3 and allow non-conforming optimizations on all other routines. Perhaps the state of x87 fp hardware does not permit this mixed operation?

Could someone elaborate on this?

Thanks,
Kyle

[Steven_L_Intel1]

Kyle,

You seem to be confusing two different options.

/fpe controls the handling of floating point operations that result in an IEEE exceptional value (NaN, Inf) or denormalized value. The default, /fpe:3, is to allow such operations to create the appropriate valiue. Other options are /fpe:1 (same as 3 except that underflows are flushed to zero) and 0 (overflows, invalids and zerodivides generate an exception, underflows are flushed to zero). All of these require that the Fortran main program be compiled with the switch as it controls an initial setting of the FP status registers done only in Fortran main programs.

/fp (-fp-model on Linux and MacOS) controls the semantics of floating point operations as affected by optimizations such as reassociation. There are various flavors of this switch some of which have more impact on performance than others. We introduced "source" (aka "precise") to deliver more "consistent" results by always rounding to source precision and doing only value-safe optimizations. If your program wants to dynamically change the FP rounding or exception modes, then you need to use /fp:except.or strict. The default is fast:1 and there is a fast:2 which allows more aggressive optimizations. /fp does not depend on a Fortran main program.

The Compiler Options manual gives a lot more detail on these.

From your description, you MIGHT want to compile certain routines with /fp:source if you find that optimizations are giving you results that are not as consistent (same in every context) as you'd like. Without this, you might see small differences depending on order of operation and when rounding took place.

[TimP]

A small problem: -fp:precise aren't supported until ifort 9.1. One of several valuable improvements.

[Steven_L_Intel1]

Ah, I forgot we were discussing an old version. Quite right.

[drgfthomas]

I'm using v9.1 but it's not obvious to me as how to set /fp:precise from the VS 2003 IDE. Propery Pages..Fortran..Floating-Point .. Floating-Point Consistency is still there. I've tried (in DEBUG config) adding /fp:precise to the Additional Options but it doesn't appear to show up in the Command Line. When I try to build the project it fails with

ifort: Command line warning: ignoring option '/fpconstant'; no argument required

fortcom: Error: Unknown option "-Qvc7.1 -Qlocation,link,C:Program FilesMicrosoft Visual Studio .NET 2003Vc7in"

FWIW the command reads

/nologo /Zi /Od /G5 /fpp /define:_DEBUG /warn:interfaces /real_size:64 /Qsafe_cray_ptr

/module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /check:bounds /libs:static /threads

/dbglibs /c

What now?

[Steven_L_Intel1]

Gerry,

I just tried it and it worked fine for me to add /fp:precise in Additional Options. You're right that this option is not yet exposed in the property pages. I'm also puzzled by that error you're getting for the options that come from ifort.cfg. There may be a connection.

[drgfthomas]

Thanks, I got it working, the problem seemed to be spawned by my failue to invoke a VC++ .lib (of my creation) statically linked to an IVF DLL.

All I get now is a warning:

ifort: Command line warning: /fp:precise evaluates in source precision with Fortran

after each .f90 in the project is compiled, which I guess is benign. Yes, on changing 'precise' to 'source' the warnings are no more.

[Steven_L_Intel1]

Yeah, in the C++ compiler, source and precise mean different things, but not for Fortran.

[Ben_W_]

Steve,

I wasn't actually confusing options, but I am guilty of confusing the discussion by expanding the scope of discussion from just /fp to include /fpe. I should have declared my intent. Both are potentially important to me, as I am led to believe both can affect overall IEEE conformance: /fp for normal values and /fpe for exceptional values.

Your desccription of fpe here is the best I've seen yet. Adding a statement similar to yours above to the /fpe docs would help I think. ("All of these require that the Fortran main program be compiled with the switch as it controls an initial setting of the FP status registers done only in Fortran main programs.")

This discussion adds to the docs and has been very helpful to me.

Thanks,
Kyle

[pdonahue]

To expand upon this thread, I would like to know the best way to detect floating point exceptions on Linux using version v9.1.x of the C++ compiler.

Compiler documentation shows:

-fp-model enable floating point model variation
[no-]except - enable/disable floating point semantics
double - rounds intermediates in 53-bit (double) precision
extended - rounds intermediates in 64-bit (extended) precision
fast[=1|2] - enables more aggressive floating point optimizations
precise - allows value-safe optimizations
source - enables intermediates in source precision
strict - enables -fp-model precise -fp-model except, disables
contractions and enables pragma stdc fenv_access

I've changed compilation to use "-fp-model strict" but I still have floating point operations that are returning "nan". Going to try wrapping all the calls with try/catch blocks now to see if I can see any exceptions.

[Steven_L_Intel1]

Well, you're in the Windows forum, but.. -fp-model (/fp on Windows) does not change exception behavior - it changes what optimizations the compiler is allowed to do. I would suggest you see if -fpe0 does what you want. Note that the main program must be in Fortran and must be compiled with -fpe0 for any effect.