[PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

Segher Boessenkool segher@kernel.crashing.org
Sun Aug 16 01:16:43 GMT 2020


Hi!

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 :-)

> +bool
> +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
FP_SNANS_ALWAYS_SIGNAL?

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 :-/

Thanks,


Segher


More information about the Gcc-patches mailing list