https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #1 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Additional surprising behavior...
On the following C code:
void g (void);
double f (void)
{
double x = 0.0, y = 0.0;
double r = x / y;
g ();
return r;
}
one can see with -ftrapping-math (the default) that a 0.0 / 0.0 is done before
the call to g, which is the expected behavior (this time, the order of the
operations has been preserved):
pxor %xmm0, %xmm0
divsd %xmm0, %xmm0
movsd %xmm0, 8(%rsp)
call g@PLT
movsd 8(%rsp), %xmm0
(note that with -fno-trapping-math, a NaN is just generated at compile time).
But on the following C code:
void g (void);
double f (void)
{
double x = 1.0, y = 3.0;
double r = x / y;
g ();
return r;
}
GCC behaves as with -fno-trapping-math, i.e. g is called, then the rounded
value of 1/3 is returned, while there should have been an inexact exception
(the GCC manual explicitly mentions inexact as one of the possible traps).
