- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
25 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Try setting, under Code Generation, Enhanced Instruction set, the option for "no enhanced instruction set (/arch:ia32) and see if that changes things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
My "real" source is now declared all double precision -- real(8) but the same thing occurs.
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Linda, I'll take a look.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
are you sure this isn't a compiler bug?
found a couple of instances where single precision was being used. changed and attached.
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, I'm not sure - yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page