Re: [PATCH] LoongArch: Add soft floating-point fe* function implementations.

[Xi Ruoyao <xry111@xry111.site>]

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 
> not fully implemented,
> lacking functions for handling soft float exceptions/rounding modes. 
> 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.  
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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University