From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 1CBCA3858C56 for ; Thu, 13 Oct 2022 13:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CBCA3858C56 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-pf1-x42f.google.com with SMTP id y191so1898110pfb.2 for ; Thu, 13 Oct 2022 06:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g6Frj4EOXAHu+vvwfqYyuF/vEcJ3fACAyIfj7K02MeE=; b=pmmaLQ4APbZlvh2ue4OAsPdfR2uFtzdn7WGzBlx7TdQPTKUUZpt2ex9sXlzEk4L7+y LZMIourcZQb5qqqCw0CdXTiNOXSD9dP8eO/zRNPaOOUb2hWEzJ/eHxKO9kCOXh5hfU3p WpYubmQSKdS4AXv5orWv8dAMyZL3ZJu7mn2tZK0tLw2THcbg4zcelXApmW9JrBLxOk1A MF6LPNBFS31BsuW88/wHsdcvdNbAp7Nys752NGCPSX4uftveEOIj0n0lqprsowbozEFr RUgitl+flBUbtuf0Bng5o8IrutXHt1dlGqo5/l2W/dWtTUdsUkQxdSfbWcTIC8UcxEPw f1EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g6Frj4EOXAHu+vvwfqYyuF/vEcJ3fACAyIfj7K02MeE=; b=ObA+OClNo7qFgpDmJ5vGHCZe2shM4xt9PK+znPjB/rW1JnXv0PZ8GnA8T0ZBEpl7+S bLJtnCd+2JItfRwodUvSu1NZ12MEBIk8BGEF2TxJ3mCKKXkDhznT6kGbH7QNElvYiTcB xwfGLFP7brThmrI97N8TxLdyirBaBMJAbRHWMh+WzHI++Uxyxe4AZJy1qJh7yRN5zDZd v0VT+nO3vFbwOeY1zhwDexpa64n4KJPz6PfMFKTSWs2Yi4Vmhdmn4aq/4xltOWxATGMu VD3sTEKXL+bvJQfJZni+6aESX7nBKO0oI9rmpyqZV5HqbGbm0TkUrSDMSxSr6mFkyMxR JXzA== X-Gm-Message-State: ACrzQf3kFFA8BUaUkluYnqIkpIdw4ikYVfYjjo+d2cbCky2uVSyOo4+1 wEwLAnbDcZ8oW4uWNgYtG08O+SO1PhDGYDYBnqp8cbnK+KMuLkSx X-Google-Smtp-Source: AMsMyM6LR5XmeEeErHPJv+Nrdtl3x3n+jXOknLmSPQ8M3BhdOKsV16tHBIaPZ8YKhZLMG/hwmEbESrMKDMCSTrWWxAo= X-Received: by 2002:a63:5766:0:b0:440:2960:37d with SMTP id h38-20020a635766000000b004402960037dmr30523119pgm.278.1665666151802; Thu, 13 Oct 2022 06:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20221006150137.18691-1-fantasquex@gmail.com> In-Reply-To: <20221006150137.18691-1-fantasquex@gmail.com> From: Letu Ren Date: Thu, 13 Oct 2022 21:02:28 +0800 Message-ID: Subject: Re: [PATCH v5] stdlib/strfrom: Add copysign to fix NAN issue on riscv (BZ #29501) To: libc-alpha@sourceware.org Cc: fweimer@redhat.com, joseph@codesourcery.com, schwab@suse.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: > According to the specification of ISO/IEC TS 18661-1:2014, > > The strfromd, strfromf, and strfroml functions are equivalent to > snprintf(s, n, format, fp) (7.21.6.5), except the format string contains = only > the character %, an optional precision that does not contain an asterisk = *, and > one of the conversion specifiers a, A, e, E, f, F, g, or G, which applies= to > the type (double, float, or long double) indicated by the function suffix > (rather than by a length modifier). Use of these functions with any othe= r 20 > format string results in undefined behavior. > > strfromf will convert the arguement with type float to double first. > > According to the latest version of IEEE754 which is published in 2019, > > Conversion of a quiet NaN from a narrower format to a wider format in the= same > radix, and then back to the same narrower format, should not change the q= uiet > NaN payload in any way except to make it canonical. > > When either an input or result is a NaN, this standard does not interpret= the > sign of a NaN. However, operations on bit strings=E2=80=94copy, negate, a= bs, > copySign=E2=80=94specify the sign bit of a NaN result, sometimes based up= on the sign > bit of a NaN operand. The logical predicates totalOrder and isSignMinus a= re > also affected by the sign bit of a NaN operand. For all other operations,= this > standard does not specify the sign bit of a NaN result, even when there i= s only > one input NaN, or when the NaN is produced from an invalid operation. > > converting NAN or -NAN with type float to double doesn't need to keep > the signbit. As a result, this test case isn't mandatory. > > The problem is that according to RISC-V ISA manual in chapter 11.3 of > riscv-isa-20191213, > > Except when otherwise stated, if the result of a floating-point operation= is > NaN, it is the canonical NaN. The canonical NaN has a positive sign and a= ll > significand bits clear except the MSB, a.k.a. the quiet bit. For > single-precision floating-point, this corresponds to the pattern 0x7fc000= 00. > > which means that conversion -NAN from float to double won't keep the sign= bit. > > Since glibc ought to be consistent here between types and architectures, = this > patch adds copysign to fix this problem if the string is NAN. This patch > adds two different functions under sysdeps directory to work around the > issue. > > This patch has been tested on x86_64 and riscv64. > > Resolves: BZ #29501 > > v2: Change from macros to different inline functions. > v3: Add unlikely check to isnan. > v4: Fix wrong commit message header. > v5: Fix style: add space before parentheses. > Signed-off-by: Letu Ren > --- > I'm not sure about copyright of the new file I created and the name of > the new function. Please give me some advice. Thanks. Hi, it has been almost a week since this patch was sent. I'm looking forward to any response. Thanks. Letu Ren