From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id C12683857C4A
 for <gcc-patches@gcc.gnu.org>; Sun, 16 Aug 2020 01:16:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C12683857C4A
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=fail smtp.mailfrom=segher@kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 07G1GiE9030726;
 Sat, 15 Aug 2020 20:16:44 -0500
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 07G1GhLL030723;
 Sat, 15 Aug 2020 20:16:43 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Sat, 15 Aug 2020 20:16:43 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: "'GCC Patches'" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce
 tree_expr_maybe_nan_p et al.
Message-ID: <20200816011643.GU6753@gate.crashing.org>
References: <004901d672f4$b80b66f0$282234d0$@nextmovesoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004901d672f4$b80b66f0$282234d0$@nextmovesoftware.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR,
 T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2020 01:16:47 -0000

Hi!

On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote:
> I'll quote Joseph Myers (many thanks) who describes things clearly as:
> > (a) When both arguments are NaNs, the return value should be a qNaN,
> > but sometimes it is an sNaN if at least one argument is an sNaN.

Where is this defined?  I can't find it in C11, in 18661, and of course
it isn't what GCC does (it requires -fsignaling to even acknowledge the
existence of signaling NaNs :-) )

> > (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
> > result should be a qNaN (whereas if one argument is a qNaN and the
> > other is not a NaN, the result should be the non-NaN argument).

I cannot find that first part.

>       if (tree_expr_maybe_signaling_nan_p (arg0) ||
>           tree_expr_maybe_signaling_nan_p (arg1))
>         return RECURSE (arg0) && RECURSE (arg1);

This new function returns false if !HONOR_SNANS, so this looks good :-)

> +bool
> +tree_expr_maybe_signaling_nan_p (const_tree x)

> +    case MIN_EXPR:
> +    case MAX_EXPR:
> +      return tree_expr_maybe_signaling_nan_p (TREE_OPERAND (x, 0))
> +	     || tree_expr_maybe_signaling_nan_p (TREE_OPERAND (x, 1));

Can those ever return a SNaN?  What does GCC do for
FP_SNANS_ALWAYS_SIGNAL?

All looks good to me except the SNaN stuff (which may be just me not
understanding it).  I find "maybe_" stuff very hard to read and
understand btw, but there may be no escaping that :-/

Thanks,


Segher