From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id DFB143858D28 for ; Mon, 24 Apr 2023 16:33:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFB143858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-52160f75920so3405108a12.2 for ; Mon, 24 Apr 2023 09:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682354020; x=1684946020; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=pJePVIFqz3LIaH8m9U6OoXVZmAXNdyrwhM9SH/UVbfI=; b=hOyHw3XGIsPQEgBXPn+jN4hKdzMNx6I93ibxv44k2c0QFjI96WlNola8oahcE9utd9 bi8nCUq2J67iHD8SaiN+BT5d7dQR6OdhE+gl8g7E66XXdOcwT6k6fZN5h5ww+nFc1MpO UHWDYzT45Qw83T30lVPi1EIGvU/s1vjWe874yOux9Ibd5J08GxBbHkRhxYj6DNCjf0f9 q6Tx9jFapvSIGsP3GbOer4UT1rsJlWnPUq6N33++nM2iweT+wi+pdHjUEKkkUa34pqoy RNAtS+m4gJr0MYizYfcv93CFVIZQmL80BEENBZVOpp6MnF4KzW26Csj08+uKkGAK0+Bz 55tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682354020; x=1684946020; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pJePVIFqz3LIaH8m9U6OoXVZmAXNdyrwhM9SH/UVbfI=; b=HmWk5dlo/OyZILtZRg8T1GdfKmz2NfDi7nYuXv66KSdGfjw0YW5kkiFaNUaHfhbHoX WuPjYdkqZKBt22PALYUgzHnnan29Lqeh9Fg52RTpDql0rkRYEceLULsv6El3K3pELroP SPH6pcUruc4zUmXllvW0q4JZMI1Ny56spJLYABPjpXWPjfJQzcJCRsTKXiPha1h/piUX 4FyzG12M7hynUwKRxo1R5+fasL5pSyFh04mwR02M6B1njwhUQhvgndBz6GjAjCEmxYog rtAdLw1KGkmjOw37ScYhvTxuOExuJLSSWwsdptcSeg+A935PfF8UDAV/eNN6zUeSP7HW Chww== X-Gm-Message-State: AAQBX9djcdMSdqOELvUjnKBl4sWf0l9N8YE4RUnKXJAROX+gy57hslz8 j49z0AR4+eCtjg+C9rPpZoI= X-Google-Smtp-Source: AKy350brh1LOp/m1ysB7p/at9OA9eoq44rzF5K2rx67UBq/fx0dQNRMrbH4nkAcr9hAa0mEJjPLGWg== X-Received: by 2002:a17:90a:9707:b0:247:31c9:65a1 with SMTP id x7-20020a17090a970700b0024731c965a1mr14434900pjo.14.1682354020350; Mon, 24 Apr 2023 09:33:40 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id iw3-20020a170903044300b0019a5aa7eab0sm6813554plb.54.2023.04.24.09.33.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Apr 2023 09:33:39 -0700 (PDT) Message-ID: Date: Mon, 24 Apr 2023 10:33:38 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] Implement range-op entry for sin/cos. Content-Language: en-US To: Siddhesh Poyarekar , Jakub Jelinek Cc: Aldy Hernandez , "Joseph S. Myers" , GCC patches , Andrew MacLeod References: <20230418131250.310916-1-aldyh@redhat.com> <64abfdef-8eae-9ce9-af62-c57c14c9ffbb@gotplt.org> <477bddf7-63e8-cfa8-a1db-330ca7bfb896@gotplt.org> From: Jeff Law In-Reply-To: <477bddf7-63e8-cfa8-a1db-330ca7bfb896@gotplt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 4/24/23 10:05, Siddhesh Poyarekar wrote: > On 2023-04-24 12:03, Jakub Jelinek wrote: >> On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote: >>>> Similarly for other functions which have other ranges, perhaps not >>>> with so >>>> nice round numbers.  Say asin has [-pi/2, pi/2] range, those numbers >>>> aren't >>>> exactly representable, but is it any worse to round those values to >>>> -inf or >>>> +inf or worse give something 1-5 ulps further from that interval >>>> comparing >>>> to other 1-5ulps errors? >> >> I've extended my hack^^^test to include sqrt and this time it seems >> that the boundary in that case holds even for non-standard rounding modes >> for glibc: > > IIRC the standard _requires_ sqrt to be correctly rounded. Correct. I spent an inordinate amount of time dealing with this in the past ;-) jeff