<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/math, branch master</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/math?h=master</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/math?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-06-17T16:31:49Z</updated>
<entry>
<title>Implement C23 exp2m1, exp10m1</title>
<updated>2024-06-17T16:31:49Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-06-17T16:31:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=7ec903e028271d029818378fd60ddaf6b76b89ac'/>
<id>urn:sha1:7ec903e028271d029818378fd60ddaf6b76b89ac</id>
<content type='text'>
C23 adds various &lt;math.h&gt; function families originally defined in TS
18661-4.  Add the exp2m1 and exp10m1 functions (exp2(x)-1 and
exp10(x)-1, like expm1).

As with other such functions, these use type-generic templates that
could be replaced with faster and more accurate type-specific
implementations in future.  Test inputs are copied from those for
expm1, plus some additions close to the overflow threshold (copied
from exp2 and exp10) and also some near the underflow threshold.

exp2m1 has the unusual property of having an input (M_MAX_EXP) where
whether the function overflows (under IEEE semantics) depends on the
rounding mode.  Although these could reasonably be XFAILed in the
testsuite (as we do in some cases for arguments very close to a
function's overflow threshold when an error of a few ulps in the
implementation can result in the implementation not agreeing with an
ideal one on whether overflow takes place - the testsuite isn't smart
enough to handle this automatically), since these functions aren't
required to be correctly rounding, I made the implementation check for
and handle this case specially.

The Makefile ordering expected by lint-makefiles for the new functions
is a bit peculiar, but I implemented it in this patch so that the test
passes; I don't know why log2 also needed moving in one Makefile
variable setting when it didn't in my previous patches, but the
failure showed a different place was expected for that function as
well.

The powerpc64le IFUNC setup seems not to be as self-contained as one
might hope; it shouldn't be necessary to add IFUNCs for new functions
such as these simply to get them building, but without setting up
IFUNCs for the new functions, there were undefined references to
__GI___expm1f128 (that IFUNC machinery results in no such function
being defined, but doesn't stop include/math.h from doing the
redirection resulting in the exp2m1f128 and exp10m1f128
implementations expecting to call it).

Tested for x86_64 and x86, and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>Implement C23 log10p1</title>
<updated>2024-06-17T13:48:13Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-06-17T13:48:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=55eb99e9a9d840ba452b128be14d6529c2dde039'/>
<id>urn:sha1:55eb99e9a9d840ba452b128be14d6529c2dde039</id>
<content type='text'>
C23 adds various &lt;math.h&gt; function families originally defined in TS
18661-4.  Add the log10p1 functions (log10(1+x): like log1p, but for
base-10 logarithms).

This is directly analogous to the log2p1 implementation (except that
whereas log2p1 has a smaller underflow range than log1p, log10p1 has a
larger underflow range).  The test inputs are copied from those for
log1p and log2p1, plus a few more inputs in that wider underflow
range.

Tested for x86_64 and x86, and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>Implement C23 logp1</title>
<updated>2024-06-17T13:47:09Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-06-17T13:47:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=bb014f50c4a0c8d8db1ba5af55c104e430b5533d'/>
<id>urn:sha1:bb014f50c4a0c8d8db1ba5af55c104e430b5533d</id>
<content type='text'>
C23 adds various &lt;math.h&gt; function families originally defined in TS
18661-4.  Add the logp1 functions (aliases for log1p functions - the
name is intended to be more consistent with the new log2p1 and
log10p1, where clearly it would have been very confusing to name those
functions log21p and log101p).  As aliases rather than new functions,
the content of this patch is somewhat different from those actually
adding new functions.

Tests are shared with log1p, so this patch *does* mechanically update
all affected libm-test-ulps files to expect the same errors for both
functions.

The vector versions of log1p on aarch64 and x86_64 are *not* updated
to have logp1 aliases (and thus there are no corresponding header,
tests, abilist or ulps changes for vector functions either).  It would
be reasonable for such vector aliases and corresponding changes to
other files to be made separately.  For now, the log1p tests instead
avoid testing logp1 in the vector case (a Makefile change is needed to
avoid problems with grep, used in generating the .c files for vector
function tests, matching more than one ALL_RM_TEST line in a file
testing multiple functions with the same inputs, when it assumes that
the .inc file only has a single such line).

Tested for x86_64 and x86, and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>Don't provide scalb/significand _FloatN aliases [BZ #31760]</title>
<updated>2024-05-22T13:10:54Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2024-05-20T16:56:36Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=a34f76edbda8a0b143111e670ca33c97623bfe56'/>
<id>urn:sha1:a34f76edbda8a0b143111e670ca33c97623bfe56</id>
<content type='text'>
scalb is a deprecated interface which was obsolescent in POSIX.1-2001,
removed in POSIX.1-2008, never made to C standard.  significant was
originally from BSD and never made in any standard.  Fix BZ #31760 by
not providing _FloatN aliases for them.

Signed-off-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>math: Add support for auto static math tests</title>
<updated>2024-05-21T19:53:27Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-05-21T16:52:53Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=ce6cdb94d0769e99d0779b6283f543d333553461'/>
<id>urn:sha1:ce6cdb94d0769e99d0779b6283f543d333553461</id>
<content type='text'>
It basically copy the already in place rules for dynamic tests for
auto-generated math functions for all support types.  To avoid the
need to duplicate .inc files, a .SECONDEXPANSION rules is adeed for
the gen-libm-test.py generation.

New tests are added on the new rules 'libm-test-funcs-auto-static',
'libm-test-funcs-noauto-static', and 'libm-test-funcs-narrow-static';
similar to the non-static counterparts.

To avoid add extra build and disk requirement, the new math static
tests are only enable with a new define 'build-math-static-tests'.
Reviewed-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
</content>
</entry>
<entry>
<title>math: Add more details to the test driver output.</title>
<updated>2024-05-20T14:09:54Z</updated>
<author>
<name>Joe Simmons-Talbott</name>
<email>josimmon@redhat.com</email>
</author>
<published>2024-05-20T14:09:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=ae18044f95271ed422ed847bd8d8c6d8e84674ce'/>
<id>urn:sha1:ae18044f95271ed422ed847bd8d8c6d8e84674ce</id>
<content type='text'>
Add start and end indicators that identify the test being run in the
verbose output.  Better identify the tests for max errors in the
summary output.  Count each exception checked for each test. Remove
double counting of tests for the check_&lt;type&gt; functions other than
check_float_internal. Rename print_max_error and
print_complex_max_error to check_max_error and check_complex_max_error
respectively since they have side effects.

Co-Authored-By: Carlos O'Donell &lt;carlos@redhat.com&gt;
Reviewed-By: Joseph Myers &lt;josmyers@redhat.com&gt;
</content>
</entry>
<entry>
<title>Implement C23 log2p1</title>
<updated>2024-05-20T13:41:39Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-05-20T13:41:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=79c52daf4740b00bef43e4f5a4281b3480459b38'/>
<id>urn:sha1:79c52daf4740b00bef43e4f5a4281b3480459b38</id>
<content type='text'>
C23 adds various &lt;math.h&gt; function families originally defined in TS
18661-4.  Add the log2p1 functions (log2(1+x): like log1p, but for
base-2 logarithms).

This illustrates the intended structure of implementations of all
these function families: define them initially with a type-generic
template implementation.  If someone wishes to add type-specific
implementations, it is likely such implementations can be both faster
and more accurate than the type-generic one and can then override it
for types for which they are implemented (adding benchmarks would be
desirable in such cases to demonstrate that a new implementation is
indeed faster).

The test inputs are copied from those for log1p.  Note that these
changes make gen-auto-libm-tests depend on MPFR 4.2 (or later).

The bulk of the changes are fairly generic for any such new function.
(sysdeps/powerpc/nofpu/Makefile only needs changing for those
type-generic templates that use fabs.)

Tested for x86_64 and x86, and with build-many-glibcs.py.
</content>
</entry>
<entry>
<title>math: Add GLIBC_TEST_LIBM_VERBOSE environment variable support.</title>
<updated>2024-05-14T14:39:38Z</updated>
<author>
<name>Joe Talbott</name>
<email>joetalbott@gmail.com</email>
</author>
<published>2024-05-14T14:39:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=f942a732d37a96217ef828116ebe64a644db18d7'/>
<id>urn:sha1:f942a732d37a96217ef828116ebe64a644db18d7</id>
<content type='text'>
Allow the libm-test-driver based tests to have their verbosity set based
on the GLIBC_TEST_LIBM_VERBOSE environment variable.  This allows the entire
testsuite to be run with a non-default verbosity.

While here check the conversion for the verbose option as well.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>Add crt1-2.0.o for glibc 2.0 compatibility tests</title>
<updated>2024-05-06T14:49:40Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2024-04-30T16:57:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=5f245f3bfbe61b2182964dafb94907e38284b806'/>
<id>urn:sha1:5f245f3bfbe61b2182964dafb94907e38284b806</id>
<content type='text'>
Starting from glibc 2.1, crt1.o contains _IO_stdin_used which is checked
by _IO_check_libio to provide binary compatibility for glibc 2.0.  Add
crt1-2.0.o for tests against glibc 2.0.  Define tests-2.0 for glibc 2.0
compatibility tests.  Add and update glibc 2.0 compatibility tests for
stderr, matherr and pthread_kill.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>math: x86 trunc traps when FE_INEXACT is enabled (BZ 31603)</title>
<updated>2024-04-04T17:29:28Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-04-03T19:39:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=44ccc2465c6af5bd811d8258bf744aaafd5392fc'/>
<id>urn:sha1:44ccc2465c6af5bd811d8258bf744aaafd5392fc</id>
<content type='text'>
The implementations of trunc functions using x87 floating point (i386 and
x86_64 long double only) traps when FE_INEXACT is enabled.  Although
this is a GNU extension outside the scope of the C standard, other
architectures that also support traps do not show this behavior.

The fix moves the implementation to a common one that holds any
exceptions with a 'fnclex' (libc_feholdexcept_setround_387).

Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
</content>
</entry>
</feed>
