On 11/4/11, Vincent Lefevre <vincent+gcc@xxxxxxxxxx> wrote: > On 2011-11-04 01:28:00 +1100, leon zadorin wrote: >> On 11/3/11, Vincent Lefevre <vincent+gcc@xxxxxxxxxx> wrote: >> > 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. > > Hmm... Yes, this should be possible. But I'm not sure this is easy. > The reason is that the rounding mode used at compile time may be > different than the rounding mode used at run time, so that there > may be an overflow when an expression is evaluated at compile time > (in which case the compile-time evaluation is discarded, AFAIK[*]) > while there will be no overflows at run time. In such a case, a > warning could be regarded as a bug. > > [*] From Kaveh R. GHAZI in the gcc mailing-list on 2008-01-03: > > "So I tried that, but mpfr_gamma on that value sets the global underflow > flag. If overflow/underflow are set by mpfr, GCC will intentionally > bypass folding. So this particular case is not something I can use." Aha, now this is very interesting :-) :-) With very aggressive optimization options (-ffast-math et al) gcc 4.6.1 (from my memory - I'm typing away from coding box), the following code: float x(::std::numeric_limits<float>::max()); float y(x * 2); appeared to produce an Inf at compile time (eg the runtime detection of fpu status was not sensing overflow, but indeed the value of y when printed or examined otherwise was Inf)... When, however, an extern function, taking address of x in its signature yet doing nothing (in implementation in a different translation unit compiled without -FL to but with -fno-lto etc), was called between the above 2 lines, the run-time fpu status was correctly showing an overflow after y evaluation... So... I am happy to have it either way: a) compiler does do it at compile time (differences wrt run-time calculations are not an issue as those will always be there in pretty much all of the "unsafe optimization options" for the floating point math - like associative grouping, rounding modes, hardware fpu register architecture which may not be ieee standard anyway and have a different accumulating precision loss when temps are being stored in registers, etc...); ... but it should emit a diagnostic (if one is uncomfortable calling it a warning, the just call it a verbosity output, just like the -ftree-vectorizer-verbose meaning). b) compiler does not do it at compile-time if its calculated evaluation yields non-finite value (although things like Nan are obtainable vis div by zero legitimately.. I think... but I digress); ... but may be it does not do this currently if things like -ffinite-math are being set? Personally I would suggest, ever so slightly, the former option - verbosity output. The compiler, from the info you had quoted, does already sense the non-finite states of its evaluations, and if it does decide to go ahead with writing the value at compile-time (eg may because the optimization options infer this), then might as well print a message about it... and if the semantics of a warning are too drastic, then just call it a verbosity-related output :-) Of course, I must say - I am way out of my depth here wrt compiler internals... I know nothing... I shall retest the aforementioned code as soon as I get a chance... best regards leon zadorin. > -- > Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> > 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> > Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) >
