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

[caiyinyu <caiyinyu@loongson.cn>]

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


>