[PATCH] fold-const: Don't consider NaN non-negative [PR97965]

[Roger Sayle]

Many thanks for including me on this discussion.  It's extremely
interesting...

NaNs have a sign-bit, so copyexpr (and negate and ABS_EXPR) are
well-defined,
and it's reasonable for nonnegative_p to reflect this.  IMHO, the true bug
is that
we can't fold away (any) comparisons against NaN when flag_trapping_math,
irrespective of qNaN, -qNaN, sNaN or -sNaN.

My completely untested solution is the attached patch.  My apologies, I'm
not
even set up to compile things on the laptop that I'm composing this e-mail
on,
but my notes/proposals on tackling PR97965 are easier expressed as the
actual
suggested changes/edits.  [Forgive me if I've made a typo].

As Joseph correctly points out, signaling NaNs are a red herring here, as
both
sNaNs and qNaNs may trap during regular (ordered) comparisons.

The piece that I'll leave to the (C++) front-end folks to argue, is whether
constexpr
implies -fno-trapping-math like initializers, c.f.
START_FOLD_INIT/END_FOLD_INIT
in fold-const.c.  This controls whether the test case should be consistently
true or
consistently false, but the patches above address Jakub's concern in the PR
that
things should at least be consistent.

I hope this helps.  I'm happy to spin this patch myself but it may take a
little while.
Hopefully, this is sufficient to point folks in the right (or one possible)
direction.

Best regards,
Roger
--
Roger Sayle
NextMove Software Limited
Cambridge, UK

-----Original Message-----
From: Richard Biener <rguenther@suse.de> 
Sent: 26 November 2020 10:04
To: Jakub Jelinek <jakub@redhat.com>
Cc: Joseph S. Myers <joseph@codesourcery.com>; Jason Merrill
<jason@redhat.com>; gcc-patches@gcc.gnu.org; roger@nextmovesoftware.com
Subject: Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, 26 Nov 2020, Jakub Jelinek wrote:

> On Thu, Nov 26, 2020 at 09:16:29AM +0000, Richard Biener wrote:
> > > So, I really don't know if we want this or not, posting it for
discussions.
> > 
> > Is copysign (x, NaN) supposed to be well-defined?  We'd stop folding 
> > this then, no?
> 
> Yes, we'd stop folding several cases with NaNs.
> 
> >  I think the ABS_EXPR<x> < 0 to false folding is simply incomplete 
> > and should first check whether the operands are ordered?  That said, 
> > NaN is nonnegative but NaN < 0 isn't false(?)
> > 
> > So I don't think the patch is good.
> 
> Another possibility (if we have this optimization already in match.pd 
> too) would be to only optimize the < 0 case in GENERIC if !HONOR_NANS 
> like the >= 0 case is and only optimize it in GIMPLE.  Though with the 
> default -ftrapping-math I think even optimizing qNaN < 0 to 0 is 
> incorrect, even that should raise invalid exception, shouldn't it?
> So perhaps add a defaulted argument to the *nonnegative* APIs that 
> would say whether unordered is ok or not?

Roger recently added some exhaustive changes in related areas, so let's see
if he has anything to say here.

Richard.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201126/c934e5e6/attachment.txt>