Compile-time floating-point expressions and subsequent detection of possible overflows etc -- during the compile-time stage.

[leon zadorin]

On 11/3/11, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> On 2011-11-03 00:36:20 +1100, leon zadorin wrote:
>> I dont think that this is the point i am making... Gcc allows certain
>> optimization options eg -Ofast (4.6) where -ffast-math (even prior to
>> 4.6), and some other, unsafe wrt pedantic standard definitions,
>> optimization options become available (including, i think
>> floating-point constant folding opportunities).
>>
>> I am very happy with such options by the way so the question was not
>> about standard compliance (hence my original statement about the said
>> compile-time calculations being done under certain conditions, not all
>> the time and having nothing to do with c++03/11 standard
>> specifications).
>>
>> I am saying that having such, great, otimization options available it
>> would be super-helpful if there was a way to have a diagnostic/warning
>> about compile-time calculations producing non-finite floating point
>> values (whether via lib mpfr or otherwise).
>
> I'd say that this wouldn't be much useful, because similar problems
> can also occur at run time, and if you use options like -ffast-math,
> you won't be able to tell whether your program works correctly...
> unless you can prove that no overflows (etc.) can occur. But if you
> can do that, you no longer need GCC to do this for you for the
> particular case of compile-time calculations.

But as I had mentioned in my original post -- there is a way to detect
this at runtime, even if compiler optimizes based on presumptions of
finite math etc implied by -ffast-math.

If, as a statistical outlier, the two variables (whose values are only
known at run time) are say multiplied together and an overflow occurs
- the fpu hardware (for example) sets the fpu status registers to
indicate the overflow... which is what I was referring to in my
original post: "via reading the FPU status register, which hardware
itself may flag appropriately; or via the 'fetestexcept' et al
wrappers". One can even do the run time verification via an external
link to 'isfinite' function (compiled from a differently-optimized
translation unit without the -ffinite-math et al) - ie individually
guarding various expressions. The only thing being that 'fetestexcept'
is much more efficient in some cases (as once again I think i had
mentioned in my original post).

in other words - just as there is a run time after-the-fact way to
observe/detect unexpected non-finite values which is very useful in
some petformance-oriented deployment scenarios-- it would also be good
to do so for the compile-time stage also (ESP. when it is the compile
state which produces such values).

regards leon zadorin.