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

leon zadorin leonleon77@gmail.com
Thu Nov 3 15:56:00 GMT 2011


On 11/4/11, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> On 2011-11-04 01:28:00 +1100, leon zadorin wrote:
>> On 11/3/11, Vincent Lefevre <vincent+gcc@vinc17.org> 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@vinc17.net> - 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)
>



More information about the Gcc-help mailing list