From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 26273385220E for ; Thu, 17 Nov 2022 20:43:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26273385220E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,172,1665475200"; d="scan'208";a="90181493" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 17 Nov 2022 12:43:25 -0800 IronPort-SDR: nMSE+sKs1EfhA4eRgUgnRVKCIz516AciTuupBxDX9GjQlkYuzkGg2+9jXNlR5Q1zaBuC1bByEU RsQHKHx9tTNDG8s8v/3dwpGQGhyfFL5ewf4HvtVrKlNwaX+p1DMkxLc4Vj3cyQkHWLi+beLb5Q eKuWtnaTZbO81KROpKBJn0WIkyuwraHqg3h5zGUycaXdQZXtF8oh4fnEuorimOIZCENJuTbkE2 a9M+jOKnKohgH4Fj/ohM7JEuc8tQevyPL4XoXlEMQOHdpZSkq7TfnNEZHuW0T/p9JgYdO71sLl 4hs= Date: Thu, 17 Nov 2022 20:43:20 +0000 From: Joseph Myers To: Jakub Jelinek CC: Aldy Hernandez , GCC patches , Andrew MacLeod Subject: Re: [PATCH] [range-ops] Implement sqrt. In-Reply-To: Message-ID: <8e22b2f-bb4-8c33-17c6-bd7da3b7b1f5@codesourcery.com> References: <20221113200553.440728-1-aldyh@redhat.com> <6150f7fd-5a57-c138-f65e-8dc3bf13d11a@codesourcery.com> <4441fc8a-e9e1-6fdd-20d1-473d10122426@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3109.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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, 17 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > On Thu, Nov 17, 2022 at 06:59:45PM +0000, Joseph Myers wrote: > > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote: > > > > > So... is the optimization wrong? Are we not allowed to substitute > > > that NAN if we know it's gonna happen? Should we also allow F F F F F > > > in the test? Or something else? > > > > This seems like the usual ambiguity about what transformations > > -ftrapping-math (on by default) is meant to prevent. > > > > Generally it's understood to prevent transformations that add *or remove* > > exceptions, so folding a case that raises "invalid" to a NaN (with > > "invalid" no longer raised) is invalid with -ftrapping-math. But that > > doesn't tend to be applied if the operation raising the exceptions has a > > result that is otherwise unused - in such a case the operation may still > > be removed completely (the exception isn't properly treated as a side > > effect to avoid dead code elimination; cf. Marc Glisse's -ffenv-access > > patches from August 2020). And it may often also not be applied to > > "inexact". > > The problem is that the above model I'm afraid is largely incompatible with > the optimizations ranger provides. That model is more an empirical description of when the nominal -ftrapping-math semantics tend to be respected, than a coherent design for any kind of API commitment to what the option does or what the default trapping-math rules are. -- Joseph S. Myers joseph@codesourcery.com