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

[Florian Weimer <fweimer@redhat.com>]

* Xi Ruoyao:

> 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.

That's a behavioral change, not an ABI change.

> 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).

No, this was done to keep Adobe Flash working:

  Strange sound on mp3 flash website  
  <https://bugzilla.redhat.com/show_bug.cgi?id=638477>

In general, we do not promise bug-for-bug compatibility.

> 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!

On the other hand, if an application keeps using the stub despite this
warning, I think it should be prepared for turning into a real
implementation.

> 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.

Yes, it's possible to add a compat symbol for that and keep the
do-nothing behavior for old applications.

Wouldn't the issue manifest on other architectures with a working
(non-stub) feenableexcept implementation?

Thanks,
Florian