Extended precision

[tjt]

Quick query.

I might be completely wrong with this but are dynamically allocated real*8 arrays stored at 80 bits while static arrays are stored at 64 bits?

If so, is there a way to disable this so the stack is at 64 bits?

Thanks in advance

TJ.

[TimP]

This can't be quick, as it's not clear what you have in mind.

ifort has no way to store real*8 in 80-bit format.

The /Qpc options are still described in the Windows .chm help file, but I suppose you would need to be using the 32-bit (ia32) compiler with architecture option set to ia32 (/arch:IA32 or -mia32, according to Windows or linux).  This subject still isn't close to your wording.

[Steven_L_Intel1]

The simple answer to what you seem to be getting at is "No, they aren't, so just use the default options and you won't get any 80-bit floats." Even if you used a 32-bit compiler and used the options Tim mentions, at best you'd get intermediate calculations in 80-bit registers but they'd never get stored to memory that way. The default is to use the precision you declare and the SSE instructions used for floating point don't have an 80-bit option.

[tjt]

Many thanks for the responses!

Sorry for not being clearer in my query. I am running ifort 11.1 on a 64 bit Linux machine. I am trying to determine why an modification to my code influences the value of a function.

I have a number of dynamically allocated arrays :

 real*8,save,allocatable ::     DENSITY         (:)     
 real*8,save,allocatable ::     MASS              (:)
 real*8,save,allocatable ::     PRESSURE     (:)

in my function I calculate the value of variable 'pressure_force_ij' from

 real*8     pressure_force_ij

 pressure_force_ij = ((pressure(i)+pressure(j))/2.0) * (mass(j)/density(j))

Now, if I change this to

 real*8     pressure_force_ij

 real*8     pressure_i, pressure_j, mass_j, density_j

 pressure_i = pressure(i)

 pressure_j = pressure(j)

 mass_j      = mass(j)

 density_j    = density(j)

 pressure_force_ij = ((pressure_i+pressure_j)/2.0) * (mass_j/density_j)

 I should get the same value but I find that I get a very slightly difference. This is evident as the pressure force value exhibits positive feedback behaviour. I thought that this could be explained by the dynamic and static variables being stored at differing precisions but it would appear that this is not the case.

I am compiling with flags -O2 -openmp -xAVX -traceback -check bounds

Any ideas on why the change would effect the result?

[TimP]

If you are looking for the parentheses to force the same order of evaluation in the two cases, you should add the option -assume protect_parens (or an option which includes that).   As far as I know, the lack of default status for this option is a historical question (might even involve your suspicions about past extended precision options).

Depending on how this code is used, -prec-div may also have an effect; without it, the compiler will look for opportunities to replace /density_j by 1/density_j * (which has numerical implications), as well as replacing /2.0 by *0.5 (which is completely safe and seems unnecessary to be controlled by -prec-div).

I don't know at which version ifort began having problems with allocatable under the -openmp option; I think that would be subsequent to the final 11.1 version (and appears to be corrected in the latest 13.1 and 14.0 versions).  In the 11.1 series also, it would be preferable to use the final update version.

[tjt]

Hi,

Thanks for the response. Neither of the compiler options had any effect on the solution. I will play around with the code to see if I can determine the cause or, alternatively, just turn a blind eye to this...

With kind regards

TJ

[Martyn_C_Intel]

 Tim covered the effects and switches that seemed most likely to be responsible.   However, if you build with -fp-model precise, that should suppress all the optimizations that might lead to small variations in results. See the article attached at http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/ for more detail than you proably want to know. If that doesn't help, check carefully that you don't have typos in any of your type declarations - use implicit none, and perhaps -real-size=64.