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
