]> git.ipfire.org Git - thirdparty/glibc.git/commit
math: Fix non-portability in the computation of signgam in lgammaf
authorVincent Lefevre <vincent@vinc17.net>
Fri, 22 Nov 2024 16:54:53 +0000 (13:54 -0300)
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>
Mon, 25 Nov 2024 12:20:47 +0000 (09:20 -0300)
commit68d71289425bb133c6cbf0f5065da6b1d99f81fc
tree87bf881cae7c1a7d986ba455d88a2709f29cf6fa
parentc621d4f74fcbb69818125b5ef128937a72f64888
math: Fix non-portability in the computation of signgam in lgammaf

The k>>31 in signgam = 1 - (((k&(k>>31))&1)<<1); is not portable:

* The ISO C standard says "If E1 has a signed type and a negative
  value, the resulting value is implementation-defined." (this is
  still in C23).
* If the int type is larger than 32 bits (e.g. a 64-bit type),
  then k = INT_MAX; line 144 will make k>>31 put 1 in bit 0
  (thus signgam will be -1) while 0 is expected.

Moreover, instead of the fx >= 0x1p31f condition, testing fx >= 0
is probably better for 2 reasons:

The signgam expression has more or less a condition on the sign
of fx (the goal of k>>31, which can be dropped with this new
condition). Since fx ≥ 0 should be the most common case, one can
get signgam directly in this case (value 1). And this simplifies
the expression for the other case (fx < 0).

This new condition may be easier/faster to test on the processor
(e.g. by avoiding a load of a constant from the memory).

This is commit d41459c731865516318f813cf4c966dafa0eecbf from CORE-MATH.

Checked on x86_64-linux-gnu.
sysdeps/ieee754/flt-32/e_lgammaf_r.c