On Wed, Sep 02, 2020 at 04:55:14PM -0400, Jason Merrill via Gcc-patches wrote:
> C++ says that division by zero has undefined behavior, and that an
> expression with undefined behavior is not constant, so we shouldn't fold
> 1./0 to inf anyway. The same is true of other trapping operations. So
> clearing flag_signaling_nans, flag_trapping_math, and flag_trapv seems wrong
> for C++. And folding_initializer seems to be used for the same sort of
> thing.
I indeed see:
"If during the evaluation of an expression, the result is not mathematically
defined or not in the range of
representable values for its type, the behavior is undefined. [Note: Treatment
of division by zero, forming a
remainder using a zero divisor, and all floating-point exceptions vary among
machines, and is sometimes
adjustable by a library function. — end note]"
Now, for floating point exceptions, we have several of them.
I'd hope the inexact one shouldn't count, because otherwise we can't
evaluate at compile time pretty much nothing (but we actually seem to ignore
inexact during fold const except for rounding math).
The other exceptions are invalid, which is for the not mathematically
defined cases (0 / 0, inf - inf and the like), yes, they can be expressed as
NaNs, but I guess the above make it undefined.
Then there are overflows into infinities, should that count as not
representable?
Underflows are more like inexact I'd say.
So perhaps we should have a special flag that fold-const.c checks next to
flag_signalling_math and decide what is and is not undefined.
Jakub
