Re: [PATCH] Implement __builtin_issignaling

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Aug 15, 2022 at 12:07:38PM +0000, Richard Biener wrote:
> Ah, I misread
> 
> +static rtx
> +expand_builtin_issignaling (tree exp, rtx target)
> +{
> +  if (!validate_arglist (exp, REAL_TYPE, VOID_TYPE))
> +    return NULL_RTX;
> +
> +  tree arg = CALL_EXPR_ARG (exp, 0);
> +  scalar_float_mode fmode = SCALAR_FLOAT_TYPE_MODE (TREE_TYPE (arg));
> +  const struct real_format *fmt = REAL_MODE_FORMAT (fmode);
> +
> +  /* Expand the argument yielding a RTX expression. */
> +  rtx temp = expand_normal (arg);
> +
> +  /* If mode doesn't support NaN, always return 0.  */
> +  if (!HONOR_NANS (fmode))
> +    {
> +      emit_move_insn (target, const0_rtx);
> +      return target;

I think I can expand on the comment why HONOR_NANS instead of HONOR_SNANS
and also add comment to the folding case.

> which doesn't use HONOR_SNANS but still HONOR_NANS and thus
> -ffinite-math-only.  You possibly want MODE_HAS_NANS instead here?

But I'm not sure we want this.  With -ffast-math/-ffinite-math-only etc.,
__builtin_isnan or __builtin_fpclassify for NaNs/Infs will just return 0,
so it would be strange if __builtin_issignaling didn't.
People usually only call __builtin_issignaling when they know they
have a NaN, so they want it guarded with
__builtin_isnan/__builtin_fpclassify or say <=> unordered.

> > That seems like a glibc bug/weird feature in the __MATH_TG macro
> > or _Generic.
> > When compiled with C++ it is rejected.
> 
> So what about __builtin_issignaling then?  Do we want to silently
> ignore errors there?

I think we should just restrict it to the scalar floating point types.
After all, other typegeneric builtins that are or can be used similarly
do the same thing.

	Jakub