On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > testcase is just invalid?
>
> Ups, that shouldn't happen. It does seem to work here
> (x86-64-gnu-linux), however, running various compile flags including -O3
> and -O2.
>
> Regarding MIN and MAX: I think the IEEE 754 decided at some point
> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> recall correctly). I think one has to check what exactly the test case
> does and what is guaranteed where. I also do not know whether a more
> recent IEEE 754 (754:2019) has changed something again.
Yes, that is what IEEE 754 says I believe.
But that is not what is provided by GCC {MIN,MAX}_EXPR or s{min,max}*
optabs.
See https://gcc.gnu.org/ml/gcc-patches/2005-01/msg01609.html that documented
it.
So, in short, the FE shouldn't emit {MIN,MAX}_EXPR if it expects the IEEE
754 behavior and should instead emit something different, like
COND_EXPR.
If one writes in C:
double foo (double x, double y) { return x > y ? x : y; }
double bar (double x, double y) { return x >= y ? x : y; }
it is also only converted into MAX_EXPR if one uses -ffinite-math-only
-fno-signed-zeros and not otherwise. Already fold-const.c can do that,
or e.g. phiopt pass.
Jakub
