From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [69.48.154.134]) by sourceware.org (Postfix) with ESMTPS id ACD62384AB4B for ; Thu, 2 May 2024 09:34:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACD62384AB4B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ACD62384AB4B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=69.48.154.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714642500; cv=none; b=DyrKSRjb09iBC0KBYgPd7BT/GOR0JH0uBSf0G8yoXDMdKjkpZTmM2nFcFqWrOAzRziqaC26bRUKayjZzwCIco31nhfZs5qtxx0Bi06y6Vk17liVrQGuhWPgpsTLc2NeFEokyljGWm8VcXwfsGAuhcvlQAFxwHmrFMsk6NfVe3aQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714642500; c=relaxed/simple; bh=f/KnqvToMxbILWMBn34C6m1cq7/0nHeR5JVWV0TXlgI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=DRhyOsl8vV5BGl0ytEt8w7MqSBjizPOSvcH6Kf6f9dflR41kFuquVmsVaA3eTkJEDv1pdsYHikdDUwwm0UhwyHP0axqnzyFZFPaKqI6zD+3da/s0L9rQYYidxCupnZ4uBl+PpkME2lYepW8q91SPFIRLHL8Z6ExvQRb8wz1Y7z4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4F5jcEiHs0XVSOhdqcgekOxR2l5+2cGQVx5hbxDNRx8=; b=CBpA6XJaJQFgrB2dPvWvJC9oKm D7iki371EQ9nB2EYg/mR4BqlAKCUUUudJJqchS0v4dlb1nVQ4rxjWGFRUuN3qqobvOd2V0mt5WbC4 yob+CIXgqdFdhsjf9d4rpdQibKPIv0ULZ+BUTPVKnMtA377aHqR+ANsQktYphH47PkPuSuppoihhl adFBz9DPWQ8wsd3y6rmSp/zFOsyOrsV30MwTKyplY6yM9GnOt29o96I3m1oIMubwW+Dz7vF6QxWKM qb5AMMrK0VimLIB6SAlrk/8VfQoLvJ+3DwwNEjPFrdtPY/Gwe5b8SgrgW0D2TKvGC0beH/tIDYgXp Z7S7w3tw==; Received: from [168.86.198.148] (port=53701 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1s2Sq9-00EAfN-2q; Thu, 02 May 2024 05:34:58 -0400 From: "Roger Sayle" To: "'Richard Biener'" , "'Joseph Myers'" Cc: References: <009201da97b2$325fc140$971f43c0$@nextmovesoftware.com> In-Reply-To: Subject: RE: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans Date: Thu, 2 May 2024 10:34:56 +0100 Message-ID: <001401da9c73$ff2bbec0$fd833c40$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFpJDeNQ4XW3FzPfj+oivxBOnliZQI7ZQOPslTBEdA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Richard Biener > On Fri, Apr 26, 2024 at 10:19=E2=80=AFAM Roger Sayle = > wrote: > > > > This patch addresses PR middle-end/111701 where optimization of > > signbit(x*x) using tree_nonnegative_p incorrectly eliminates a > > floating point multiplication when the operands may potentially be = signaling > NaNs. > > > > The above bug fix also provides a solution or work-around to the > > tricky issue in PR middle-end/111701, that the results of IEEE > > operations on NaNs are specified to return a NaN result, but fail to > > (precisely) specify the exact NaN representation of this result. > > Hence for the operation "-NaN*-NaN" different hardware = implementations > > (targets) return different results. Ultimately knowing what the > > resulting NaN "payload" of an operation is can only be known by > > executing that operation at run-time, and I'd suggest that GCC's > > -fsignaling-nans provides a mechanism for handling code that uses = NaN > > representations for communication/signaling (which is a different = but related > concept to IEEE's sNaN). > > > > One nice thing about this patch, which may or may not be a P2 > > regression fix, is that it only affects (improves) code compiled = with > > -fsignaling-nans so should be extremely safe even for this point in = stage 3. > > > > This patch has been tested on x86_64-pc-linux-gnu with make = bootstrap > > and make -k check, both with and without --target_board=3Dunix{-m32} > > with no new failures. Ok for mainline? >=20 > Hmm, but the bugreports are not about sNaN but about the fact that the = sign of > the NaN produced by 0/0 or by -NaN*-NaN is not well-defined. > So I don't think this is the correct approach to fix this. We'd = instead have to use > tree_expr_maybe_nan_p () - and if NaN*NaN cannot be -NaN (is that at = least > specified?) then the RECURSE path should still work as well. If we ignore the bugzilla PR for now, can we agree that if x is a = signaling NaN, that we shouldn't be eliminating x*x? i.e. that this patch fixes a real = bug, but perhaps not (precisely) the one described in PR middle-end/111701. Once the signaling NaN case is correctly handled, the use of = -fsignaling-nans can be used as a workaround for PR 111701, allowing it to perhaps be = reduced from a P2 to a P3 regression (or even not a bug if the qNaN case is = undefined behavior). When I wrote this patch I was trying to help with GCC 14's stage 3. =20 > > 2024-04-26 Roger Sayle > > > > gcc/ChangeLog > > PR middle-end/111701 > > * fold-const.cc (tree_binary_nonnegative_warnv_p) : > > Split handling of floating point and integer types. For = equal > > floating point operands, avoid optimization if the operand = may be > > a signaling NaN. > > > > gcc/testsuite/ChangeLog > > PR middle-end/111701 > > * gcc.dg/pr111701-1.c: New test case. > > * gcc.dg/pr111701-2.c: Likewise. > >