From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 00C953858C55 for ; Tue, 2 Apr 2024 10:40:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00C953858C55 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 00C953858C55 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712054416; cv=none; b=XI8W5H1t+ULjWeMGx6zE5pBCQMya8L0yGD/p7s7J/nqhTcDYaXWDukFBGSqrtbqSFUs5ZrCU7krsXaIKiYJxhTDi0onLkIpFDx3PVgjJdab3qrAGzE8XawSkedzGcniZjf04d+Oc4qqoaYMBJF/f2jImq2ppLqeichvZOIMuNSE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712054416; c=relaxed/simple; bh=uEWh9bcyX1FwOUvCIGw3QPCofACeai6PKnXnzYVtHZ4=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=NL7+ol14Ph3BiKOPz8uycEmHtA7RSsNmAb7eqW3NAOecAyGs7ksqezY122FXggbQo2aAmehSn4edDHwzaEQh3pv8xIfcPzjYfXe2anmXnXcduSxePetnrr+Uv1NMEmtKZ0pmiCvqgE27wtZQDOUNCW088mGrTabTjJz5HE+yMM8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1712054411; bh=uEWh9bcyX1FwOUvCIGw3QPCofACeai6PKnXnzYVtHZ4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=m6mVeVxoZLmz7V0WfG2lAll2irr/eE+KflZdNZsn10Wy538mbDyu63Ljm+X76XLXN ElaBcKa105UnRLHRlEDugQrFCs3gqvjCw/tddYQ8L242CVu/qGvipRm8XOS/LvYyeU szbZ6zTSgSUVKJx8aURXPYaQeE3k7xKDgwYMYQmM= Received: from [192.168.124.9] (unknown [113.200.174.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id A27E666F2F; Tue, 2 Apr 2024 06:40:09 -0400 (EDT) Message-ID: <98f2d5adc158e05a3fa487a8a3a3899734b97a45.camel@xry111.site> Subject: Re: [PATCH] LoongArch: Add soft floating-point fe* function implementations. From: Xi Ruoyao To: caiyinyu , Florian Weimer Cc: josmyers@redhat.com, libc-alpha@sourceware.org, adhemerval.zanella@linaro.org Date: Tue, 02 Apr 2024 18:40:06 +0800 In-Reply-To: <393612ff-b4fa-6047-d203-5b23bd96d29a@loongson.cn> References: <20240331101400.474159-1-caiyinyu@loongson.cn> <87le5x1ar2.fsf@oldenburg3.str.redhat.com> <393612ff-b4fa-6047-d203-5b23bd96d29a@loongson.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.0 MIME-Version: 1.0 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,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 Tue, 2024-04-02 at 11:40 +0800, caiyinyu wrote: > The LoongArch soft ABI was added to glibc in version 2.37[1], but it was= =20 > not fully implemented, > lacking functions for handling soft float exceptions/rounding modes.=20 > This patch fills in > the missing functions and fixes related failed test cases. > Therefore, would backporting this patch to 2.37 be sufficient? The problem is this change is breaking ABI. The behavior of feenableexcept etc. *is* a part of the ABI. For example, if a not so careful programmer invokes feenableexcept(FE_INVALID) and then mistakenly invokes something like acos(1.0000001), before this change the program will continue to run with a NaN, but after this change it'll crash with SIGFPE. You may argue such a program is buggy, but ABI stability requires that even such a buggy program should still behave, unless it's invoking an undefined behavior per the specification **when the program was built**. For example, on x86_64 Glibc still have memcpy@GLIBC_2.2.5 which is actually memmove, to support programs built before ISO C (invoking memcpy with overlapping ranges, doing so was well defined before ISO C but an undefined behavior today). In this case, the specification before Glibc 2.40 is well defined as "feenableexcept will do nothing and return an error": there is even a linker warning actively tells the user this definition! So backporting this to 2.37 is a no-go. Doing so will back-stab people relying on the ABI stability of the rolling-release branch. =C2=A0 Instead we should raise the ABI version to 2.40, so soft-fp programs linked with these Glibc-2.37 functions will refuse to run with Glibc- 2.40. This is "adding a new ABI." In the NEWS file we can tell the users "if your program errors out with `cannot find ${something}@GLIBC_2_37`, you need to relink it and test it thoroughly again to ensure it does not intentionally or unintentionally relies on the behavior predating Glibc 2.40." Or maybe we can provide both feenableexcept@GLIBC_2_37 and feenableexcept@GLIBC_2_40 in libm.so.6? I don't know if doing so is really possible. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University