> > So, for this case, there is typically no good workaround.
Maybe part of the problem can be reduced by using '#pragma STDC FENV_ACCESS'?
Haven't tried that. And it won't help fixing the issue of the i386 ABI
requiring 'float' and 'double' values in 387 registers.
Paul Eggert wrote:
> Yes, my
On 2023-10-16 16:09, Bruno Haible wrote:
In my tests so far, they seem to be reliable except on x86 and sh4 CPUs.
(For sh4, because of a gcc bug.)
I am partly relying on the GCC manual which contains the delicious
sentence "This option is experimental and does not currently guarantee
to
On 14/10/23 15:55, Bruno Haible wrote:
> On Linux/mips (all 3 ABIs) and on Linux/hppa (configuring a testdir in such
> a way that the configuration ignores the totalorder* functions provided by
> glibc and instead uses the gnulib replacement instead:
> gl_cv_func_totalorder_in_libm=no
On 10/14/23 05:53, Bruno Haible wrote:
* Programs that need to distinguish QNaN and SNaN, and that do
floating-point operations.
In these cases the 'union' workaround is typically too clumsy.
So, for this case, there is typically no good workaround.
Example: Code that wants to rely
Adhemerval Zanella Netto wrote:
> Do we have a bug similar to the one you opened for SH4 on glibc?
No, the SH4 architecture is the only one on which I identified a totalorder*
malfunction in glibc.
> But the MIPS failure is expected ...
The MIPS test failure was because MIPS uses the "inverted"
On 15/10/23 11:59, Bruno Haible wrote:
> With the new benchmark in place, I measured the run time of
> - the glibc 2.35 implementation of totalorder,
> - the gnulib implementation (picked by configuring with
> gl_cv_func_totalorder_in_libm=no gl_cv_func_totalorder_no_libm=no \
>
Jeffrey Walton wrote:
> Clang got into a code path intended for MSVC.
> ...
> #elif defined(__clang__) && defined(_MSC_VER)
We already know since 2020 [1] that
- clang for Unix masquerades as GNU C 4.2.1, by defining
#define __GNUC__ 4
#define __GNUC_MINOR__ 2
#define
