Hi!
On Mon, Dec 19, 2022 at 11:02:30AM +0100, Jakub Jelinek wrote:
> On Mon, Dec 19, 2022 at 09:49:36AM +0100, Richard Biener wrote:
> > On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin <li...@linux.ibm.com> wrote:
> > > In function fold_convert_const_real_from_real, when the modes of
> > > two types involved in fp conversion are the same, we can simply
> > > take it as copy, rebuild with the exactly same TREE_REAL_CST and
> > > the target type. It is more efficient and helps to avoid possible
> > > unexpected signalling bit clearing in [1].
> > >
> > > Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu
> > > and powerpc64{,le}-linux-gnu.
> > >
> > > Is it ok for trunk?
> >
> > But shouldn't
> >
> > double x = (double) __builtin_nans("sNAN");
> >
> > result in a quiet NaN?
No, it is no conversion, it is a no-op?
With -fno-signaling-nans, anything goes.
With -fsignaling-nans, only corge should return a qNaN *and trap*, and
it does that for me, too (it does an frsp insn on the datum, and that
has that effect).
With signalling NaNs your program should always trap when it converts a
SNaN to a QNaN. Not all operations on SNaNs can be optimised away; any
SNaN that is operated on should remain trapping. With -fsignaling-nans
very many floating point operations can not be optimised very much.
> GCC right now returns a sNaN in foo and bar and qNaN in baz, qux and corge,
> clang and ICC (tried 19.0.1 on godbolt) return sNaN in foo, bar, baz, qux
> and qNaN in corge.
I just get an lfd everywhere (so returns SNaN, doesn't trap) except in
corge(), which also does an frsp (round to SP float, so it returns a
QNaN, but traps first).
> As for the rest, C n3047.pdf has:
> Whether C assignment (6.5.16) (and conversion as if by assignment) to the
> same format is an
> IEC 60559 convertFormat or copy operation439) is implementation-defined, even
> if <fenv.h> defines
> the macro FE_SNANS_ALWAYS_SIGNAL (F.2.1).
And GCC just does a copy, already? At -O2 anyway.
> I think the posted patch is good for consistency, treating conversion to the
> same format sometimes as convertFormat and sometimes as copy is maybe valid
> but confusing, especially when on:
Agreed.
Segher
