Need compiler switch to set variables to 4-bytes in 64-bit build

[Chris_H_3]

I have some mixed C/Fortran code in VS2010.  I get different results from the 32-bit and 64-bit builds of the code.  To see if it is a precision problem, I would like to compile the 64-bit  build with a switch that forces the real and integer variables to be single precision (4-bytes).  Are there switches for the C and Fortran compilers to do this?  Please let me know.  Thank you.

[TimP]

It's not clear what you want, although reading the compiler docs would answer the question you asked.

There isn't any change in data precision inherent in switching between 32- and 64-bit mode under Visual Studio.  There are changes in default data alignments.  ifort options such as /fp:source will disable most optimizations where numerical results are expected to depend slightly on alignments.  Changes in alignment also might expose problems with undefined data or subscript range violations.  There are compiler options to help find those.

You would want to fix problems before relying on options like /align:array32byte to eliminate the differences in alignment.

[mecej4]

Chris Hobbs wrote:
 I get different results from the 32-bit and 64-bit builds of the code.

There is no difference as to standard data types (integer, real, etc.) between those builds. The main difference is that addresses are 32-bit in one and 64 in the other, and the instruction sets are somewhat different. If you have a bug-free program and you use the same FPU instructions in both (e.g., SSE2), the results should be identical most of the time.

If you see any but the smallest differences in the computed results, I should suspect that there are bugs present.

[jimdempseyatthecove]

Other than Tim's suggestion of using /fp:source and mecej4's suggestion of assuring same FPU options (pick a target, not ambiguous Host), You might try removing IPO and compiling at /O0, then incrementally advance /O1, /O2,... until something breaks. adding back /O levels first then IPO. When you reach the error point, then back off the last change in project level optimizations, and then add to individual files in the project the breaking optimization until the code breaks. This process will isolate the problem to a specific file in your project and the specific optimization level.

Note, if this is a compiler bug, you usually can continue working on your code while awaiting a bug fix by setting the properties of the affected file(s) to a lesser optimization level. Document this, and then come back to this at each compiler update.

Jim Dempsey