This is a repost of this comment originally posted to the stable update thread here: [Stable Update] 2025-02-16 - Kernels, Firefox, Qt, KDE Gear, GNOME - #75 by QAZXSW
The stable update on 2025-02-16 introduces an error in the lgammaf_r function inside glibc. This is a mathematical function that gives the logarithm of the gamma function for a given input.
Test code:
#include <iostream>
#include <cmath>
int main()
{
int dsgngam;
double dresult = lgamma_r (double (-1.0), &dsgngam);
int fsgngam;
float fresult = lgammaf_r (float (-1.0), &fsgngam);
std::cout << "dresult = " << dresult << " dsgngam = " << dsgngam << '\n'
<< "fresult = " << fresult << " fsgngam = " << fsgngam << '\n' ;
}
With current gcc from the repositories:
$ g++ lgam.cc
$ ./a.out
dresult = inf dsgngam = 1
fresult = inf fsgngam = -1
Same output with current clang from the repositories:
$ clang++ lgam.cc
$ ./a.out
dresult = inf dsgngam = 1
fresult = inf fsgngam = -1
Both dsgngam and fsgngam should be +1 in all cases, but the float case gives -1 for both compilers, which is incorrect.
The sign of the log of the gamma function should only depend on the value of the input (-1) and not on whether it is float or double, but this version of glibc treats those datatypes differently and erroneously reports that one is positive and the other is negative.
This discrepancy in turn results in unit test failures in downstream numerical software.
Should this be taken upstream? If so, should it be taken to Arch or to the glibc developers?