From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 77A9A3858C36 for ; Wed, 27 Mar 2024 08:42:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 77A9A3858C36 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 77A9A3858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711528953; cv=none; b=qM8r4PoEgq6LRdxxfSgQf1KB4NE+uNG6Nsz3ycc0vVizUoZMcQffBjs05Wgdtb8j+my97ZHflnJglxW6KhxKlZ5r8vlRz2+u18hzgQIQjW33VWwpzcS9VrGN7Mylrb2PDk7DCQEweEQHezJ0yBoriqLUAeN8O5IzcNO0ZuCdxmE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711528953; c=relaxed/simple; bh=ML3D9/dhmUVVUmnzOevjkYlmyVlvQNkHfvAI7rBFa6Y=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=MpNATLFv/vGZY1rGHQaI0o15k0ElY+dWU3tNqr8lcw/jKAUCmcGD4HT0tyQNSUTPrvhts8jokOCCNa1AzuqTRmvqtUZx1Y+sF1XTO+MngjwJRFSnYBCBQLiiVql05NDJq85fWAQT5K6XKGVTMvI6D/lD+IsBM4F605iL9F/B0d4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [10.20.4.90]) by gateway (Coremail) with SMTP id _____8Ax++jx2wNmLs8eAA--.52618S3; Wed, 27 Mar 2024 16:42:26 +0800 (CST) Received: from [10.20.4.90] (unknown [10.20.4.90]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bxb8_w2wNmEgJqAA--.15117S2; Wed, 27 Mar 2024 16:42:24 +0800 (CST) Subject: Re: [PATCH] LoongArch: Add soft floating-point fe* function implementations. To: Joseph Myers Cc: libc-alpha@sourceware.org, adhemerval.zanella@linaro.org, xry111@xry111.site, xuchenghua@loongson.cn References: <20240326124623.1245676-1-caiyinyu@loongson.cn> From: caiyinyu Message-ID: <2193d4f3-6f55-1812-5923-2845226b3011@loongson.cn> Date: Wed, 27 Mar 2024 16:42:24 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Bxb8_w2wNmEgJqAA--.15117S2 X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxWw4xJFW8Gr4ruF47Kr48uFX_yoW5AFyxpF ZIkr1vyaykJr1UX39rZwn7K345XrZYyFWUJrW8J34Fvwn8uFyvvw1vkFyqva9rGryfJryF vayYqryqgas8urXCm3ZEXasCq-sJn29KB7ZKAUJUUUUr529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUBFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU XVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8Gjc xK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0 cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8V AvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jjwZcUUUUU= X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,MIME_CHARSET_FARAWAY,NICE_REPLY_A,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: ÔÚ 2024/3/27 ÉÏÎç1:34, Joseph Myers дµÀ: > On Tue, 26 Mar 2024, caiyinyu wrote: > >> This patch accomplishes the following: >> 1. Implements soft floating-point functions to enhance compatibility and >> flexibility in environments without hardware floating-point support. > Does this actually do anything useful for users, i.e. make the software > floating-point rounding mode and exceptions state affect both user > arithmetic and functions within libc/libm? As far as I can see, while > you're building copies of some software floating-point libgcc functions > for libc, you're not doing anything to make them use the software > floating-point environment state, and not exporting them for use by users. Yes, this patch does make sense in both libc and libm and it can be proved by the following glibc tests: stdlib/tst-strtod-underflow stdio-common/tst-printf-round math/test-fenv math/test-femode{, -traps} ... Actually, without this patch, you will get the warning info something like the following when make check and the related tsts would failed or not be tested correctly. "test-fenv.c:229:(.text+0x48): warning: feclearexcept is not implemented and will always fail" Even more, the warning information appears in glibc's check logs of all the following architectures (tested with build-many-glibcs.py). csky-linux-gnuabiv2-soft m68k-linux-gnu-coldfire-soft or1k-linux-gnu-soft powerpc-linux-gnu-soft riscv64-linux-gnu-rv64imac-lp64 sh4-linux-gnu-soft ... I think all these related tsts were not tested correctly on these architectures. > > For software floating-point rounding modes and exceptions to be useful to > users, you need to follow powerpc/nofpu and export the functions from > libc. All the functions Implemented in this patch are exported from libm.so the same as powerpc nofpu. > You then need to arrange for libgcc *not* to provide the functions > when libc does (see how libgcc/configure.ac sets ppc_fp_compat depending > on glibc version, for example). And there's also the matter of providing > libc (as opposed to libm) interfaces for cases where compiler-generated > code may need to manipulate floating-point environment state without > calling libm functions (see how powerpc-nofpu provides > __atomic_feholdexcept __atomic_feclearexcept __atomic_feupdateenv > __flt_rounds and rs6000_atomic_assign_expand_fenv in the GCC back end can > generate calls to the first three of those functions - the fourth is > future-proofing for if GCC gets proper support for making FLT_ROUNDS > depend on the rounding mode in future). I've reviewed your previous commits in glibc and gcc about __atomic_feholdexcept __atomic_feclearexcept __atomic_feupdateenv and __flt_rounds and I wil make other patches to implement these functions in glibc and gcc. In summary, I believe this patch is fine except for the _atomic* and __flt_rounds functions. >