Problem with optimisation options - building multiple-precision library

[Arjen_Markus]

I am trying to build the FMZM library by David Smith for multiple-precision calculations (see https://dmsmith.lmu.build/). I can build it with ifx (version 2025.0.0) , but the test program reports a small number of errors. If I turn off the optimisation entirely, all is well, but sofar I have not been able to find a way to have at least some sort of optimisation and still have all tests succeed. By comparison: compiling with gfortran allows the highest optimisation level.

The author, David Smith, informed me that this might be due to unsafe optimisations and using intermediate results in registers:

"As you probably saw in the "troubleshooting" section of the FM user's manual,
errors can occur if a compiler does any unsafe optimizations that can violate
the IEEE standard for floating-point arithmetic.

I don't have the latest release of ifort, but I have seen cases in the past
where it gained speed by turning off some features of the IEEE standard.

Another unsafe optimization I have seen is leaving unrounded extended precision
temporaries in registers and then using that unrounded value."

So, I am looking for some "assume" option or similar to get the benefits of optimisations without the test program complaining. -assume:protect_parens is definitely not enough - I get the same number of errors. Would -fp:strict do? Or could less restrictive options work as well?

Is there any strategy possible to find out which options to use? (Besides the obvious of course)

[jimdempseyatthecove]

Have you tried /fp:consistent option?

Also, Fortran (ifort/ifx) supports REAL(16), are you requiring more precision?

(33-36 significant decimal digit precision, exponent -16382 to +16383)

Also, even with errors, do you see sufficient performance improvement with any optimizations (of the FMZM code).

Jim Dempsey

[Arjen_Markus]

I had not seen the consistency option - this seems to be -fltconsistency. I will try that.

So far, I have merely tried the test programs that come with the library, no serious research into the performance yet. I came across these errors from the test program after adjusting the makefile for ifx.

As for a REAL(16) type, the library is based on all manner of representations of multiple-precision numbers. I have no control over that :).

[Steve_Lionel · Accepted solution]

Perusing the compiler options list, I discovered /Qfp-accuracy, which I'd guess is something LLVM brings to the table. You could try the value "high" and see where that gets you. If you don't use this option, it goes by what /fp says. /fp:precise might be the first thing to try, though. There are some other interesting-looking options at Floating-Point Options  I would not use /fp:strict, as that allows for IEEE exceptional value behavior you may not be interested in.

[Arjen_Markus]

Right, I did try with "-O3 -fp:strict", that solved the errors that were reported earlier. But the other options you and Jim mention are worth a look.

[Arjen_Markus]

A first curious result: I used -fltconsistency and got a link error on one of the programs:

ifx -O3 -I./ -fltconsistency fmsave.obj fm.obj  fmzm90.obj fm_interval.obj fm_doubleint.obj fm_quadreal.obj fm_rational.obj FM_Sample_Routines.obj -o TestFMquadReal.exe TestFMquadReal.obj
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.0 Build 20241008
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.43.34809.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:TestFMquadReal.exe
-subsystem:console
fmsave.obj
fm.obj
fmzm90.obj
fm_interval.obj
fm_doubleint.obj
fm_quadreal.obj
fm_rational.obj
FM_Sample_Routines.obj
TestFMquadReal.obj
TestFMquadReal.obj : error LNK2019: unresolved external symbol __fixtfsi referenced in function TEST_C_mp_TEST16
TestFMquadReal.exe : fatal error LNK1120: 1 unresolved externals
make: *** [Makefile.ifx:23: TestFMquadReal.exe] Error 1120

This did not happen with the other test programs.

The option does solve the earlier errors, by the way. Now on to check with -fp:precise

[Arjen_Markus]

Option -O3 -fp:precise works fine as well. And I looked at the effect of optimisation. I wrote a small program that does a simple but time-consuming calculation (calculate Apéry's constant 100 times in a naïve way with 100 decimals). Without optimisation it takes 27 seconds, with either of the working optimisation options it takes 15 seconds, so the library is roughly twice as fast with these options.