g77-like FPU setup with ifort

[kbarr216]

I am trying to run some codes on Bochs and bumped into an FPU problem. Debugging with the "paranoia" floating point tests I find g77 works for me, but ifort does not! I've tried several options to get working programs.

There are two source files (.c and .f) that are supposed to be equivalent. I tested 5 binaries:gcc, g77, icc, ifort, and "ifort -mp" (this is the strict floating pointflag)

results:
-----------------------------------------------------------------
gross (my desktop)

gcc
Diagnosis resumes after milestone Number 220 Page: 10
The number of DEFECTs discovered = 1.
The number of FLAWs discovered = 1.

icc
Diagnosis resumes after milestone Number 220 Page: 12
The number of FAILUREs encountered = 2.
The number of SERIOUS DEFECTs discovered = 2.
The number of DEFECTs discovered = 3.
The number of FLAWs discovered = 1.

ifort
The number of FAILUREs encountered = 2
The number of SERIOUS DEFECTs discovered = 4
The number of DEFECTs discovered = 4
The number of FLAWs discovered = 1

ifort -mp: perfect

g77: perfect

-----------------------------------------------------------------
bochs-2.1.1
gcc: same
icc: hang on "sqrt is rounded or chopped"
ifort: not tested due to the crazy errors seen already
ifort -mp:
after milestone 7
searching for radix and precision
forrtl: severe (174): SIGSEGV
g77:
******** perfect *******

So what we see is that bochs looks like it CAN do correct floating point
programs (with g77)! I'd like to think that with switches, I can get ifort to
run with the same "environment" that g77 uses.I recently tried -pc80 as well as making sure that I'm not linked with libimf. Are there any other suggestions you have for getting code to work on bochs's somewhat braindead fpu, or is there a way to cut and paste g77s setup register(s)?

[TimP]

You haven't posted enough of your Paranoia results to know which tests are failing, nor have you divulged which type of CPU you are testing.I suppose it is double precision, as I don't know of a public float version for C. Assuming that you are running on a CPU which supports SSE2, options -xW -mp have a better chance. If you are testing the x87 code, try -mp -pc64 for double, and -mp -pc32 for single precision. Paranoia lives up to its name when it sees you mixing different precision modes. I would think that you would find plenty of pitfalls with g77 as well, according to whether you chose -ffloat-store, and whether you chose SSE2 or 387 code.

I'll try my version of Paranoia with whichever ifort I presently have installed on my laptop.

[TimP]

When I run paranoia double precision on the Pentium-M,

g77-3.4.1 produces the expected complaints about no guard bits in 387 code, due to the double rounding when running in 64-bit precision. That can be avoided by setting 53-bit precision mode, or using SSE2 code.

With either SSE2 or 387 code, a defect is reported due to the inaccuracy of glibc exp() for small arguments. If I supply an accurate exp() function, that goes away. So, that one is library-dependent. I don't know how you could have avoided those, with any standard g77 on linux.

ifort 8.0.046 doesn't produce either complaint, but it hangs if I don't use -mp. ifort must have switched over to setting 53-bit precision mode on linux, same as on Windows.

The other complaint, shared by g77 and ifort, is about double rounding of operations on sub-normals.

Of course, I've hacked up Paranoia so it would run on a variety of CPU's, some of them extinct. This includes fixing the exponent range tests so that extended register exponent range doesn't affect them.

Recent ifort versions appear to have changed some things in the Paranoia results. The read <=> write conversions no longer produce complaints about accuracy. You may not have those tests in yours. The selection of x87 precision mode doesn't affect SSE2 code, but if ifort chooses to mix x87 and SSE/SSE2 code, you won't pass Paranoia without precision mode being set so that the SSE or SSE2 and x87 instructions agree.

That leads to some curiosity; if you try to use long double in a C function called from ifort, will that still work?