[PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.
Sun Aug 16 01:16:43 GMT 2020
On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote:
> I'll quote Joseph Myers (many thanks) who describes things clearly as:
> > (a) When both arguments are NaNs, the return value should be a qNaN,
> > but sometimes it is an sNaN if at least one argument is an sNaN.
Where is this defined? I can't find it in C11, in 18661, and of course
it isn't what GCC does (it requires -fsignaling to even acknowledge the
existence of signaling NaNs :-) )
> > (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
> > result should be a qNaN (whereas if one argument is a qNaN and the
> > other is not a NaN, the result should be the non-NaN argument).
I cannot find that first part.
> if (tree_expr_maybe_signaling_nan_p (arg0) ||
> tree_expr_maybe_signaling_nan_p (arg1))
> return RECURSE (arg0) && RECURSE (arg1);
This new function returns false if !HONOR_SNANS, so this looks good :-)
> +tree_expr_maybe_signaling_nan_p (const_tree x)
> + case MIN_EXPR:
> + case MAX_EXPR:
> + return tree_expr_maybe_signaling_nan_p (TREE_OPERAND (x, 0))
> + || tree_expr_maybe_signaling_nan_p (TREE_OPERAND (x, 1));
Can those ever return a SNaN? What does GCC do for
All looks good to me except the SNaN stuff (which may be just me not
understanding it). I find "maybe_" stuff very hard to read and
understand btw, but there may be no escaping that :-/
More information about the Gcc-patches