From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3C3903858D32 for ; Mon, 13 Mar 2023 07:18:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C3903858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678691925; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rm+ck+88NtWlJKYAYqoey3Rf3sxFG9uXXP80bVwF0P4=; b=KQ9ju1TPLgHsDwokihw1nL5Cr5jvgcdhZAMGk7HTCxfv10mGIS0udNZTlmSjxc8ZQJFRUX sCI6dmet40fDQJFh5xz3XKnPsvaNGLWMwezzVsHnTWCkKF7pNUz0nsoao9zKlL5ZbwvxnP YyROpl83zDCeAh1eLoRTpZhxZxpc4sQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-RTvrVBLzNi6JQALIxd2KdA-1; Mon, 13 Mar 2023 03:18:44 -0400 X-MC-Unique: RTvrVBLzNi6JQALIxd2KdA-1 Received: by mail-wm1-f72.google.com with SMTP id az7-20020a05600c600700b003ed25435106so429598wmb.2 for ; Mon, 13 Mar 2023 00:18:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678691923; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rm+ck+88NtWlJKYAYqoey3Rf3sxFG9uXXP80bVwF0P4=; b=Do6aMQy/7V2TyEm5JlwPW9bvIrQsj2X63jULUlchGQgMp092L9hxs7eDgqwwCM+zjp +3Aoxl5XtpM52bxF/enDOFmYrPS38w6OH65LzNVkOVSpN34zaBJ+O1YDpgR8eInK5gbb H92GFlG+JMab6BiUSFUlC4UL4AR0FWpKKvo3DmSjgLsklgBZln0aZnsoAxGHf5KhAdG6 Z3OfgcalbrGMT/RlPTWf0UqawRpQVm0VN0a54crsln1QB3DtVWH/igUe1l9ov1W5nHzF lYq8DWTdli0UCK6nw9rKu5bjq49w+i3UAxKARq0Ti9nA9tm3nWe9TiGDJzIQMkPGN2bZ MM7g== X-Gm-Message-State: AO0yUKWH7X4bnpoJ1fGXi5cVCqt1LcbW/04SpF1gOcewFUikZ9ma3NxQ GwKzIgQU1esKodQfx+IQM7G4zq/qeVcygfoJg0dFtGUYqvK0EqJRZnDBPZwDrGPJmAD5tCZHmp1 so4H+EDkUjHZ441MbEg== X-Received: by 2002:a05:600c:3591:b0:3e2:1dac:b071 with SMTP id p17-20020a05600c359100b003e21dacb071mr7947149wmq.13.1678691923637; Mon, 13 Mar 2023 00:18:43 -0700 (PDT) X-Google-Smtp-Source: AK7set8AKCTbOZA6ziDHMzO4OGyg0FJC4OBVDiLJ1aInhd8t8KmtKXaEhTBmg7tvPv0KuoK2WG6/zQ== X-Received: by 2002:a05:600c:3591:b0:3e2:1dac:b071 with SMTP id p17-20020a05600c359100b003e21dacb071mr7947140wmq.13.1678691923333; Mon, 13 Mar 2023 00:18:43 -0700 (PDT) Received: from [192.168.1.201] ([139.47.42.170]) by smtp.gmail.com with ESMTPSA id q11-20020a05600c46cb00b003ebf73acf9asm10606403wmo.3.2023.03.13.00.18.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 00:18:42 -0700 (PDT) Message-ID: Date: Mon, 13 Mar 2023 08:18:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] range-op-float: Fix up -ffinite-math-only range extension and don't extend into infinities [PR109008] To: Jakub Jelinek , Richard Biener Cc: gcc-patches@gcc.gnu.org, Andrew MacLeod References: From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 3/10/23 11:29, Jakub Jelinek wrote: > On Fri, Mar 10, 2023 at 08:53:37AM +0000, Richard Biener wrote: >> Meh - I wonder if we can avoid all this by making float_widen_lhs_range >> friend of frange and simply access m_min/m_max directly and use the >> copy-CTOR to copy bounds and nan state ... after all verify_range >> will likely fail after you restore flag_finite_math_only ... > > I'll defer such changes to Aldy. > > As for verification, I think verify_range will not fail on it, it mainly > checks whether it is normalized (e.g. if minimum is frange_val_min and > maximum is frange_val_max and NaNs are possible with both signs (if NaNs > are supported) then it is VR_VARYING etc.). It doesn't check if the actual > VR_RANGE bounds are smaller or larger than the VR_VARYING bounds, there is > just equality check. > Of course, behavior of wider than varying ranges is still unexpected in > many ways, say the union_ of such a range and VR_VARYING will ICE etc. > > Now, I guess another possibility for the reverse ops over these wider ranges > would be avoid calling fold_range in the reverse ops, but call rv_fold > directly or have fold_range variant which would instead of the op1, op2 > argument have 2 triplets, op1, op1lb, op1ub, op2, op2lb, op2ub, and it > would use those const REAL_VALUE_TYPE &op??b in preference to > op?.{lower,upper}_bound () or perhaps normal fold_range be implemented > in terms of this extended fold_range. Then we wouldn't need to bother with > these non-standard franges... > >> But OK for the moment. > > Thanks, committed. I'm not a big fan of constructing ranges that break all our internal consistency checks. I'd also prefer to add another constructor (or add a flag to the current constructor) instead of making range-op-float routines friends. We also have bits in the vrange (or frange) that we could use for other semantics, especially since frange_storage can be streamlined when stored in GC/etc. I'm on PTO this week. Could we revisit this next week? And if worse comes to worse, leave it as is, and fix it properly next release? Thanks for your work on this. Aldy