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 79A763858418 for ; Mon, 11 Apr 2022 15:46:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79A763858418 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-519-3yx0C-VYORCw6S3h5Oi0zg-1; Mon, 11 Apr 2022 11:46:48 -0400 X-MC-Unique: 3yx0C-VYORCw6S3h5Oi0zg-1 Received: by mail-qk1-f198.google.com with SMTP id br18-20020a05620a461200b0069bfc9fdb0dso3035370qkb.21 for ; Mon, 11 Apr 2022 08:46:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=eccyhB96SWwVmo2liTtUJMo0wLIAaaqE+EA2YVGorMw=; b=DTl5B4lzL+V5uWYxwvYYVi8cxFpxiUNAelx+9EVg4Q8NVea9A/ifnhak3K6nzIGAVh fz45KLjT6HljX3qLXlRg3BJQ/KC8iDmT986iic6+Tww8+G9fcbSyNfFaWW+x82ftSLsH a07nwuMh92jZPvaN4CJjbg9/0UVpp1/sqPbB8LWdf/V++mO4430FswOJdsuTF3azpwhI WWJm9CmbW7gZ6KTX4XGeyt4veVPDE/xfzkug+cH7zE3KLeLYmEHeHCtQ+cH4n78L0vbo +J/tThCi8kav+rUqQPYKvi842W6Mthbum3BHUo/wcHkfWFj63yVYd/YLpWm+Bisv6ZgT jjmA== X-Gm-Message-State: AOAM532XeVOW74mbiEJykvLZNKYdgWix1cdndWYTGtFqTa6KNCdNv3uq hgUqP5BToj0E8LbFSYDsSkUpLK6M8+SUzKOURUAKOeTYnom0p+4NfS+j7sLWR8dnAH2twMmCcWc Jw4K+T0lsyjqe6WRdLLcg X-Received: by 2002:a05:6214:22c:b0:432:6b2b:95d0 with SMTP id j12-20020a056214022c00b004326b2b95d0mr27238604qvt.63.1649692007286; Mon, 11 Apr 2022 08:46:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0+rmTl5m+QheHzoCcm4TmO2Rhx56dANYNdK0DgB+n4BwuvV1H042ve6ECNefvjx/6VEMySA== X-Received: by 2002:a05:6214:22c:b0:432:6b2b:95d0 with SMTP id j12-20020a056214022c00b004326b2b95d0mr27238576qvt.63.1649692006953; Mon, 11 Apr 2022 08:46:46 -0700 (PDT) Received: from [192.168.0.241] (135-23-175-80.cpe.pppoe.ca. [135.23.175.80]) by smtp.gmail.com with ESMTPSA id c1-20020a05620a0ce100b0067e0cd1746fsm17933726qkj.51.2022.04.11.08.46.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Apr 2022 08:46:46 -0700 (PDT) Message-ID: <334b46e3-7ffa-7fef-922b-f4a304f3616f@redhat.com> Date: Mon, 11 Apr 2022 11:46:45 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] manual: Avoid name collision in libm ULP table [BZ #28956] To: Adhemerval Zanella , Tom Coldrick , libc-alpha@sourceware.org References: <20220405094654.111306-1-thomas.coldrick@codethink.co.uk> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.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_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:46:50 -0000 On 4/5/22 07:16, Adhemerval Zanella via Libc-alpha wrote: > > > On 05/04/2022 06:46, Tom Coldrick via Libc-alpha wrote: >> The 32-bit and 64-bit variants of RISC-V share the same name - "RISC-V" >> - when generating the libm error table for the info pages. This >> collision, and the way how the table is generated, mean that the values >> in the final table for "RISC-V" may be either for the 32- or 64-bit >> variant, with no indication as to which. >> >> As an additional side-effect, this makes the build non-reproducible, as >> the error table generated is dependent upon the host filesystem >> implementation. >> >> To solve this issue, the libm-test-ulps-name files for both variants >> have been modified to include their word size, so as to remove the >> collision and provide more accurate information in the table. >> >> An alternative proposed was to merge the two variants' ULP values into a >> single file, but this would mean that information about error values is >> lost, as the two variants are not identical. Some differences are >> considerable, notably the values for the exp() function are large. > > Path looks ok, but is there any expectation that RV64 and RV32 hardware > floating-point implementation or compiler generate code to have different > precision? Otherwise it would be simple to just use one ulp tests file. That is a good question, but it could be handled with a distinct patch to remove the files if the maintainers consider that the right direction to take. Overall this patch looks correct to me also and I've pushed it as trivial in that it makes the manual more correct. I tested the patch on x86_64 with make pdf and the table looks good and disambiguates the results. Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell -- Cheers, Carlos.