https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #19 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Aurelien Jarno from comment #18)
> >
> > However looks like there's a different problem lurking under the hood so let
> > me run it by this group who care about these subtleties.
> >
> > Consider following test: -O2 -march=rv64gc -mabi=lp64d
> >
> > `
> > int myisnan(double __x)
> > {
> > return __builtin_isnan(__x);
> > }
> > `
> >
> > generates
> >
> > `
> > myisnan:
> > feq.d a0,fa0,fa0
> > xori a0,a0,1
> > ret
> > `
> >
> > FEQ.D is a quite comparison meaning it *can* set the invalid operation
> > exception flag if either input is a signaling NaN.
>
> I think it is what we want no? In addition this is what is currently used by
> the GLIBC code.
Yeah I was just pointing a different/orthogonal potential existing issue. That
current __builtin_isnan() can potentially raising an FP exception (Invalid op).
This could be fine for its intended usage in round builtin, but not sure if
that is fine as a general API / implementation agreement etc.
> At the end it seems the GLIBC round code is correct and widely tested, so we
> just want to mimic it in the builtin.
Yes totally agree on that.
