This code doesn't work correctly when optimized. Can this be fixed?

[dajum]

The code in the attached project gives bad answers when compiled in an optizmized mode. If the sub2.for source is compiled with optimization disabled it works fine. But the same construct occurs in a number of places in our code and it seems to give bad answers if optimized. I've tested this in 9.0.

The console1 project is set to build this. The sub2 file has optimization disabled so it runs correctly as sent. enable optimization for the file and it will run incorrectly.

Thanks

Dave

[Steven_L_Intel1]

The answers are not bad with optimization. It's actually the unoptimized results which are suspect. You're converting three values from double to single and then back to double and seeing if the end result is the same as the original. The values you've chosen are not exactly representable in single (or double) so there will be small differences between the two datatypes.

Why do you expect something different?

[dajum]

I don't think you looked at the code close enough. The precision is very carefully tracked the purpose of the code is to store a double precision value in 2 single precision values. Conversion are done on the delta so that when the 2 single precision values are converted back to double and added, they will equal the original dp value. This has worked fine for 20+ years on more than half a dozen compilers. The optimized code is definitely wrong. All the numbers are easily represented in DP. The deltas or 1e-7 1e-8 and 1e-9 are also easily represented in SP values. So doing the conversions using SNGL and DBLE should work correctly in the optimized version.

Dave

[dajum]

One thing that I think may be important, but don't know for sure is that the values are in a common block. The same code without common blocks worked okay in some of my tests to generatethis simple sample problem.

Dave

[Steven_L_Intel1]

Ok, I see what you are saying. Let me look at this some more.

[TimP]

It looks like you need either -Qfp_port or -QxW option, so that the single precision value which is stored is the one subtracted from the double precision value.
When you say "optimized," it is reasonable to assume you set at least -QxW, but your report indicates that you may not have done so. I would agree that the non-SSE2 code with -Qfp_port isn't optimized, if you want to make that point.

[Steven_L_Intel1]

Adding the option /fp:precise resolves the issue.

[Jeffrey_A_Intel]

dajum wrote:

All the numbers are easily represented in DP. The deltas or 1e-7 1e-8 and 1e-9 are also easily represented in SP values.

A quibble:the numbers in question can beapproximated by IEEE single- or double-precision values. They cannot be exactly represented in either format although the error is less than 1 LSB. Using 0.0000001 as an example, the IEEE single-precision representation is slightly larger than 0.0000001 while the double-precision representation isslightly smaller, but there are no other representations which are closer to 0.0000001.