On 11/3/11, Vincent Lefevre <vincent+gcc@xxxxxxxxxx> 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.
