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.129.124]) by sourceware.org (Postfix) with ESMTPS id 1EF8B3858D39 for ; Mon, 13 Mar 2023 07:59:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1EF8B3858D39 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=1678694359; 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=tCvSSn4LI0if3+bVVBlhYKLUVGSopMeWwQQEbh456nk=; b=W+kzfA9PQYx6cJ7wyT/0n7YaUd7sXYdFH9OOHVmF+DixlpFx+llnUftSfoeX6NNMDYzwcs JqXsc60ApK+pHJybocL0Oa7MsKAgDG43B00dyJBu8Ny6Veskx1VgzwzwtEioGq640NOLBL vRWae3+ktTkKRvyZacH2jJ0+EalkM+0= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-623-3qrh9d14MAC_d3zkv7RDsQ-1; Mon, 13 Mar 2023 03:59:18 -0400 X-MC-Unique: 3qrh9d14MAC_d3zkv7RDsQ-1 Received: by mail-wm1-f71.google.com with SMTP id j13-20020a05600c190d00b003ed26189f44so729439wmq.8 for ; Mon, 13 Mar 2023 00:59:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678694357; 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=tCvSSn4LI0if3+bVVBlhYKLUVGSopMeWwQQEbh456nk=; b=O7trT/wA8qYm074E1DjFTrQfCnHgFsqVnS6S5fMIhIEAJPm90iOoJzxou3CxTL9E1c OppdIeQKzpgjiA2xTpYFQKc8OlnHy13DaHbek4dZSTEEFHB4glNzQ8n6kynPE9o0n4sT 7KZLSOZLOiuWpBSERVhb8GZbahkRKVPbGePG5c4n4atijKZfUARslPv8kDC/+VREr73g cJwMvOlBYC8qYwIED5L7QkcL56+zXVNfz0DMC6EZkbELVECN1xVUKyC7oSG2mroE7DwE lEtTYl6yRvxbiqAyns2pfpBF3deWP4eBA0um/WbzJwUl4P3fSLelHdKzEvbz+zsGrTdj qQzg== X-Gm-Message-State: AO0yUKVQ37uJGBVJehfHsWg0elWmqAuo3465/io17qAjdNIeaOj8rIck UVvunCJiF6rw0GCCtBUw9AiaSRZesds+DazvoCoEW5XGGVa2zUpqa/iZA17GkdhAzLrNk4TSGmz Ly6VAdYOuTfWZKlO+9Q== X-Received: by 2002:a05:600c:4fce:b0:3ed:24f6:1089 with SMTP id o14-20020a05600c4fce00b003ed24f61089mr1620345wmq.15.1678694357326; Mon, 13 Mar 2023 00:59:17 -0700 (PDT) X-Google-Smtp-Source: AK7set+sWfmdCyVj2Sn0wjZcAfCnQAL0+xS2UINV+tv4BuNXzPadaSqkURcLi4UgxhuIad3bPgrbBw== X-Received: by 2002:a05:600c:4fce:b0:3ed:24f6:1089 with SMTP id o14-20020a05600c4fce00b003ed24f61089mr1620329wmq.15.1678694356962; Mon, 13 Mar 2023 00:59:16 -0700 (PDT) Received: from [192.168.1.201] ([139.47.42.170]) by smtp.gmail.com with ESMTPSA id q20-20020a1cf314000000b003ebfc075eaasm8164986wmq.16.2023.03.13.00.59.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 00:59:16 -0700 (PDT) Message-ID: Date: Mon, 13 Mar 2023 08:59:15 +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: Richard Biener Cc: Jakub Jelinek , 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/13/23 08:50, Richard Biener wrote: > On Mon, 13 Mar 2023, Aldy Hernandez wrote: > >> >> >> 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? > > Yes, sure - I just noticed that we're forced to use high-level API for > something that's quite low-level and should be internal (a range > "breaking" internal consistency checks). Yeah, let's fix the API. No sense hacking around things if what we need is to tweak the design. I don't like hacking around things. It always comes back to bite me ;-). Aldy