/fp:strict vs /fp:precise or source

[lklawrie]

I have a set of code that calculates the volume of a polyhedron based on vertices of the space.
With fp:precise or source in V11 compiler I get incorrect values. I believe these were correct in earlier versions of the compiler.
I still get correct results with /fp:strict.

I believe when I went to the 11 compiler I just changed "compilers" -- no change in settings.

Should I report this one?

Linda

[TimP]

If it's not due to a documented change, such as the change from default x87 code to default SSE2, or the changed meanings of /QxB and /QxK.

[lklawrie]

Quoting - tim18

If it's not due to a documented change, such as the change from default x87 code to default SSE2, or the changed meanings of /QxB and /QxK.

I did not intentionally have any of the q flags on though it looks like "speculation" was "fast". How would I figure out the cause?

Default settings appeared to be okay.

Linda

[Steven_L_Intel1]

My first guess, as was Tim's, would be the change in default for code generation to assume Pentium 4 and SSE2 instructions instead of x87. This will often change floating point results as x87 could give you "extra" precision.

Try setting, under Code Generation, Enhanced Instruction set, the option for "no enhanced instruction set (/arch:ia32) and see if that changes things.

[lklawrie]

Quoting - Steve Lionel (Intel)

My first guess, as was Tim's, would be the change in default for code generation to assume Pentium 4 and SSE2 instructions instead of x87. This will often change floating point results as x87 could give you "extra" precision.

Try setting, under Code Generation, Enhanced Instruction set, the option for "no enhanced instruction set (/arch:ia32) and see if that changes things.

that setting and /fp:precise worked okay. i.e. gave correct answers.

previously the "code generation" was "not set"

Linda

[Steven_L_Intel1]

Ok - that means that your program depends on computations being carried out in greater than declared precision - not a good thing for long-term reliability, especially as this extra precision is not predictable.

[lklawrie]

Quoting - Steve Lionel (Intel)

Ok - that means that your program depends on computations being carried out in greater than declared precision - not a good thing for long-term reliability, especially as this extra precision is not predictable.

How can that be? do you want to see this source (and test file). It's only 4 files and small files at that.

Linda

[Steven_L_Intel1]

Yes, I'd like to see the program. You can create a ZIP and attach it to a reply here (see below for attach instructions.)

How can it be? If your program is very sensitive to last-bit differences in FP results and a single-precision computation was computed in double-precision using X87 code, it could get different results than one using SSE instructions and computing in declared precision.

For more than a decade I've seen complaints from customers about inconsistent FP expression results and/or differences from other vendors that did not have the peculiarities of the X87 FP model. The change in the default to use SSE means not only faster programs but more consistent results.

[lklawrie]

And so /fp:strict somehow goes back to the x87 way? I'm certainly confused.

My "real" source is now declared all double precision -- real(8) but the same thing occurs.

Linda

[Steven_L_Intel1]

Thanks, Linda, I'll take a look.

[lklawrie]

Quoting - Steve Lionel (Intel)

Thanks, Linda, I'll take a look.

Did you ever get anywhere with this? The only way I can make it work is by turning off the extensions (using Iarch32 or whatever that switch is).

(I did find a couple of precision problems in the module but fixing them didn't help)

Linda

[Steven_L_Intel1]

I reproduced the problem easily enough but had to deal with other issues and could not dive into it deeper. Perhaps I'll get a chance to do so next week.

[lklawrie]

Quoting - Steve Lionel (Intel)

I reproduced the problem easily enough but had to deal with other issues and could not dive into it deeper. Perhaps I'll get a chance to do so next week.

I'll attach the latest version of my module -- where i weeded out (I think) any single precision problems.

Linda

[Steven_L_Intel1]

Thanks. One thing I did discover is that any attempt to "instrument" the code, to display intermediate values, makes the problem go away. I'm fairly certain that I'll find the program depends on the X87 register format with extended precision, but perhaps I'll be surprised.

[lklawrie]

Quoting - Steve Lionel (Intel)

Thanks. One thing I did discover is that any attempt to "instrument" the code, to display intermediate values, makes the problem go away. I'm fairly certain that I'll find the program depends on the X87 register format with extended precision, but perhaps I'll be surprised.

So far, I've run the little test with /fp:strict /speculation=fast and that's okay.
and /fp:strict and speculation=off and that's okay. So certainly not specifying extended precision unless some how /fp:strict makes it show up.

not sure I attached the correct module this morning and also including the "staticverify" which I might have done before I added some more double precision to the module. A little disconcerting in the static verify warnings.

Linda

[lklawrie]

putting aprint statement in the middle of a do loop and it seems to run okay (correctly) with /fp:source

are you sure this isn't a compiler bug?

found a couple of instances where single precision was being used. changed and attached.

Linda

[Steven_L_Intel1]

No, I'm not sure - yet.

[Steven_L_Intel1]

Linda, would you please attach the source for your new module DATAPRECISIONGLOBALS? If you've made changes in other sources, such as TestVolume.f90, attach that too. I tried coming up with my own DATAPRECISIONGLOBALS but it caused other errors.

[lklawrie]

Quoting - Steve Lionel (Intel)

Linda, would you please attach the source for your new module DATAPRECISIONGLOBALS? If you've made changes in other sources, such as TestVolume.f90, attach that too. I tried coming up with my own DATAPRECISIONGLOBALS but it caused other errors.

Here's the whole thing. Including solution, test file in/out (you can now call from command line).

Linda

[Steven_L_Intel1]

Linda,

It appears that you were encountering a compiler bug, one that is fixed in the upcoming 11.1 release (May/June). With that compiler, I get the correct results without specifying /arch:ia32, /fp or /fp-speculation.

[lklawrie]

Quoting - Steve Lionel (Intel)

Linda,

It appears that you were encountering a compiler bug, one that is fixed in the upcoming 11.1 release (May/June). With that compiler, I get the correct results without specifying /arch:ia32, /fp or /fp-speculation.

Glad it will be fixed and glad it wasn't just my imagination...

Linda