Consistency with long double

[velvia]

Hi,

I am working on a C++ program which is heavy on number crunching. After an update of the program that has nothing to do with floating points (I have added non floating point members to some classes), I realized that there was a slight change in the floating point results of the program. The difference is very small (a small drift starting from 1ulp), but it is there.

I've tracked the difference in between the 2 versions of the program, until I found the culprit : a routine that was using the type "long double". When changed to "double", the difference went away.

Is there any reason why some "external change" to a code might affect "long double" computation and not computation with "double" ?

Best regards,

Francois

[Kittur_G_Intel]

Hi,
You can refer to a good read on consistency of floating point results which goes over some of the compiler switches you can use to set appropriate granularity for floating point semantics in your application depending on the context of your application at:

https://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/

BTW, the error may result due to rounding intermediate results or due to precision mapped to double/long double (double precision/extended double precision) etc as well. Basically, if you have an option of using more than one data type for a variable, use of double comes first instead of long double from efficiency of the floating point optimization is concerned as well.

_Kittur

[velvia]

Hi Kittur,

I have tested both versions of the program with:

-fp-model source -no-prec-div -no-prec-sqrt

and the problem is still there. It seems that the use of "long double" makes the program "unstable" which does not happen when using double. It turns out that using "long double" in the first place is useless and was a mistake of the programmer, but I would like to understand what's going on here.

[TimP]

With so many possibilities, perhaps you could define the issue better.  Are you running in 32 bit mode with some or all functions built with " ia32" architecture? Are multiple compilers involved? Linux, Mac? 32 or 64 bit Os? Are the quoted options the full group used for main()?

[Kittur_G_Intel]

@velvia:  Tim makes a good point in that you probably need to elaborate the issue in terms of the build and target platform details. Also, which version of the compiler you're using? Invoking %icc -V   outputs the version and build info.   Also, try using "-fp-model precise -fp-model source"  i as  the option instead of just fp-model source.  

Other than that,  if you can reproduce the issue on a small reproducer then compile that test case with -P  option which will generate the pre-processed file (.i suffix) which you can attach to this issue?  I can then investigate further accordingly, appreciate much.

_Kittur

[velvia]

Hi Kittur,

This problem is found with the Intel compiler, gcc and clang. The Intel compiler I was using is 15.x.x, on Linux on x86_64.

I have tried with "-fp-model precise -fp-model source" but it does not make a difference.

Unfortunately, it is difficult to extract the code and make a small reproducer. I'll guess I need to work hard on that if I want to understand what's going on.

[Kittur_G_Intel]

@velvia:  If that's the case then it's hard to decipher what's going on as I thought it could be related to floating point optimizations per-se. Since it's also happenning with gcc and clang there's something going on in the code. Try reduced optimizations and see if it helps to narrow down. Again, yes it'll be great if you can attach a reproducer for further investigation else it's not easy to do find out, thanks.

_Kittur