From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id C04DD3858C66 for ; Fri, 3 May 2024 10:23:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C04DD3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C04DD3858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714731794; cv=none; b=edCi+Yc3Ov9AK7JuiuGbUAnbHQhc9n+nlFFu/RI7Zicte37ouH0fHOulTKeviA0Jv7lyD0uVIAGKn9+WlUB0w5YHHoXSFf3lW8gyrA9zYJ7LLYx1j3j/apySj65M1HVoROkc41RQro17IS9OeuQmsNIme0aubIIpmO94PZeG2bA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714731794; c=relaxed/simple; bh=m3sPF+4fWRZGcvCU63o5rB+pcFIMGZtmBsBKAjTmNE4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=wpkApzULfpphDmgq/qRxZ+hDUwWuvpOrCqLvEau1dVNHxmp4+B7tY1n0wJEUZAItWDamhjmbt4Ddm9rNNyy0/mzBUI1o/1dK4ONa/8h4ZwrazS+yiNe0xLdi02VBGaVQAg8125wUFldKsIz1qtRVScbCJ6x1L/t/fNPxZeHPLgM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5171a529224so11136722e87.0 for ; Fri, 03 May 2024 03:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714731790; x=1715336590; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BrYwUFswvsedcb0/cmWM29N+ZmZZfnWTehDLPuNlCmw=; b=Tgr6pVYLw07xfR0urkCeIGzJuYYv4ywfLY4BEdkZ+deXHwCPmkO1Fvz32AA5AADnVO f7EQbmAKwlQbtFS82/MuCbn9xe818sEDudZdqILjPDRCnOWttqevBzhEdOtp+iUnuVHI mboWxpa8D8Ss9+Ho9YAUr7taO5t3McWKKUirzPfJkWK3bShZaEBVlCuFb5qp3tTLZ2Ip PQX3GxswviQkjHvT+6nFbB6k10bo48TNXXEhqbgBO6VO8ofAsR81D2dsfplIhz1xmExi RGufHTLYmphUPXP1ZlLaFcgApokOvbY+rhNOM3jpJWhUN0EObiA9FgVOTxrvS/B4U+yS j1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714731790; x=1715336590; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BrYwUFswvsedcb0/cmWM29N+ZmZZfnWTehDLPuNlCmw=; b=iFNzErjs1IH5jWD1I/hFHugimIm3c371XFkoSdw/sC9sk3KPEEvgYAn2CNqEsVBeCX bVn2K8POPWc6k4TAw5yTdpHJ5bFrWSykrCRNU9csziX/hFDrhP2AlfVv+g7vqYGfP7F+ Z2vATs8i7n2lA1iRDrGDqq21kbfhD3A7hbI6mVdIXCOCyqHaVfJeSQ7Y2xrjic9vSwUs +L7nanLOZ7dZJrP7xuXgs9Qvuo5z7IbhNXYHl1pvT8Xa0Us/nISnYENfvhMfLNTOHvhM 5uXQ6O1NtPvHSmhV1qeNGCpuLwfLw378aNck+hItWK9lHYD8pZeGrpJK1Ndp/PJkcLgA SSWQ== X-Forwarded-Encrypted: i=1; AJvYcCVg4DmQTP6RNnvxxl67aYkEnfXnkhZXGlW6ouYwXVh3y41EmuH2/9435B8/6jdJ9U9MDBqAtApexT/A77M/NoXxi+9vdpC8Pg== X-Gm-Message-State: AOJu0YxJX6EZ4+UKs1q5FTvjQZmotDAcnjjoUPoLRoH8ceP7wt2iX0yh GN7JLVK8yZHtPQqEwGZ8VWjqsZRUBxUjqlVUEtkRCmPE4GFsyMni0Nc3ddjXNFrUTriUI+WdJ7Y 3vKuhsdGvUJ/VyZQqD2thGw84IX0= X-Google-Smtp-Source: AGHT+IGhax5e2K7KEPTYru+lMrMQLam7y2DHJH8GgdkCQpipoT7rO57patIYYp4JJUsbPQBSDvLP1+Vubsq0f7gE/88= X-Received: by 2002:a05:6512:3ba:b0:51c:d528:c333 with SMTP id v26-20020a05651203ba00b0051cd528c333mr824092lfp.20.1714731789796; Fri, 03 May 2024 03:23:09 -0700 (PDT) MIME-Version: 1.0 References: <009201da97b2$325fc140$971f43c0$@nextmovesoftware.com> <001401da9c73$ff2bbec0$fd833c40$@nextmovesoftware.com> <00a201da9c97$78ab54e0$6a01fea0$@nextmovesoftware.com> In-Reply-To: <00a201da9c97$78ab54e0$6a01fea0$@nextmovesoftware.com> From: Richard Biener Date: Fri, 3 May 2024 12:22:58 +0200 Message-ID: Subject: Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans To: Roger Sayle Cc: Joseph Myers , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: On Thu, May 2, 2024 at 3:48=E2=80=AFPM Roger Sayle wrote: > > > > From: Richard Biener > > On Thu, May 2, 2024 at 11:34=E2=80=AFAM Roger Sayle > > wrote: > > > > > > > > > > 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 b= e > > > > > 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 p= oint 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 mainlin= e? > > > > > > > > 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-def= ined. > > > > 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 canno= t > > > > 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. > > > > This might or might not be covered by -fdelete-dead-exceptions - at lea= st in the > > past we were OK with removing traps like for -ftrapv (-ftrapv makes sig= ned > > overflow no longer invoke undefined behavior) or when deleting loads th= at might > > trap (but those would invoke undefined behavior). > > > > I bet the C standard doesn't say anything about sNaNs or how an operati= on with > > it has to behave in the abstract machine. We do document though that i= t > > "disables optimizations that may change the number of exceptions visibl= e with > > signaling NaNs" which suggests that with -fsignaling-nans we have to pr= eserve all > > such traps but I am very sure DCE will simply elide unused ops here (al= so for other > > FP operations with -ftrapping-math - but there we do not document that = we > > preserve all traps). > > > > With the patch the multiplication is only preserved because __builtin_s= ignbit still > > uses it. A plain > > > > void foo(double x) > > { > > x*x; > > } > > > > has the multiplication elided during gimplification already (even at -O= 0). > > void foo(double x) > { > double t =3D x*x; > } > > when compiled with -fsignaling-nans -fexceptions -fnon-call-exceptions > doesn't exhibit the above bug. Perhaps this short-coming of gimplificati= on > deserves its own Bugzilla PR? With optimization you need -fno-delete-dead-exceptions to preserve the multiply. Btw, the observable trap is there even without -fnon-call-except= ions and a trap isn't an exception. So what I do not necessarily agree with is that we need to preserve the multiplication with -fsignaling-nans. Do we consider a program doing handler() { exit(0); } x =3D sNaN; ... sigaction(SIGFPE, ... handler) x*x; format_hard_drive(); and expecting the program to exit(0) rather than formating the hard-disk to be expecting something the C standard guarantees? And is it enough for the program to enable -fsignaling-nans for this? If so then the first and foremost bug is that 'x*x' doesn't have TREE_SIDE_EFFECTS set and thus we do not preserve it when optimizing __builtin_signbit () of = it. Richard. > > > So I don't think the patch is a meaningful improvement as to preserve > > multiplications of sNaNs. > > > > Richard. > > > > > 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. > > > > > > > > 2024-04-26 Roger Sayle > > > > > > > > > > gcc/ChangeLog > > > > > PR middle-end/111701 > > > > > * fold-const.cc (tree_binary_nonnegative_warnv_p) > MULT_EXPR>: > > > > > Split handling of floating point and integer types. For = equal > > > > > floating point operands, avoid optimization if the operan= d 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. > > > > > > > > > > > >