Open matoro opened 4 months ago
Thanks for helping here and providing test logs. I'll ask our Gentoo guy, if he could produce results for other versions of the glibc for comparison, so we can get a better picture of where we stand.
For the record, the above result is for glibc @28bf4783d9dfe6174de0fc90681da444a028e2a3 with ia64 patches (6150fa376ba9094d1d094ed86b4ea4bb7e8b88d8, 08eb8d5ea763cc2ce80e63439cfdbb3afb359575) on top.
Thanks for helping here and providing test logs. I'll ask our Gentoo guy, if he could produce results for other versions of the glibc for comparison, so we can get a better picture of where we stand.
For the record, the above result is for glibc @28bf4783d9dfe6174de0fc90681da444a028e2a3 with ia64 patches (6150fa3, 08eb8d5) on top.
Just for clarity, this runs in a chroot, so you can run the test script specified above on any distro.
The results from last in-tree version (2.38):
Summary of test results:
188 FAIL
4426 PASS
70 UNSUPPORTED
20 XFAIL
3 XPASS
No longer failing:
3d2
< FAIL: elf/tst-audit28
New failures:
5a5,7
> FAIL: elf/tst-tunables
> FAIL: math/check-abi-libm
> FAIL: math/test-ceil-except-2
22a25
> FAIL: math/test-double-log2p1
49a53
> FAIL: math/test-float-log2p1
57a62
> FAIL: math/test-float128-log2p1
73a79
> FAIL: math/test-float32-log2p1
@matoro : Thanks for the clarification and the comparison values and sorry for the low participation ATM, but I'm currently trying to bring OpenBSD/sgi forward a little by finally compiling the base system and release files for version 7.3. Unfortunately I was struck with hardware issues on my build machine and some "incompatible" software changes slowing the process down considerably.
We also have a patch available that is based on an earlier patch from Aurelien Jarno that @lenticularis39 extended somewhat before glibc dropped ia64 and that brought the number of failures down by nearly 15 % but also increased the number of passes considerably (on Debian (right side) it looked even better):
Summary of test results:
201 FAIL
4417 PASS
70 UNSUPPORTED
18 XFAIL
2 XPASS
Summary of test results: Summary of test results:
171 FAIL 164 FAIL
4500 PASS 4511 PASS
20 UNSUPPORTED 24 UNSUPPORTED
18 XFAIL 18 XFAIL
2 XPASS 2 XPASS
@matoro : I now added two new *-epic branches that include the partial math FPU error fix mentioned in https://github.com/linux-ia64/glibc-ia64/issues/1#issuecomment-2159207950 on top:
@matoro : I now added two new *-epic branches that include the partial math FPU error fix mentioned in #1 (comment) on top:
* https://github.com/linux-ia64/glibc-ia64/tree/master-epic * https://github.com/linux-ia64/glibc-ia64/tree/release/2.39/master-epic
Thanks, results from master:
$ EGIT_OVERRIDE_REPO_GLIBC=https://github.com/linux-ia64/glibc-ia64 EGIT_OVERRIDE_BRANCH_GLIBC=master-epic ../dotest.sh =sys-libs/glibc-9999
FAIL: debug/tst-backtrace4
FAIL: dlfcn/tst-dlinfo-phdr
FAIL: elf/tst-dl_find_object
FAIL: elf/tst-dl_find_object-static
FAIL: elf/tst-tunables
FAIL: malloc/tst-malloc-alternate-path-malloc-check
FAIL: malloc/tst-malloc-alternate-path-mcheck
FAIL: math/check-abi-libm
FAIL: math/test-ceil-except-2
FAIL: math/test-double-atan2
FAIL: math/test-double-ceil
FAIL: math/test-double-cosh
FAIL: math/test-double-erfc
FAIL: math/test-double-exp
FAIL: math/test-double-exp10
FAIL: math/test-double-exp2
FAIL: math/test-double-fdim
FAIL: math/test-double-floor
FAIL: math/test-double-fmax
FAIL: math/test-double-frexp
FAIL: math/test-double-hypot
FAIL: math/test-double-j1
FAIL: math/test-double-lgamma
FAIL: math/test-double-log2p1
FAIL: math/test-double-pow
FAIL: math/test-double-remainder
FAIL: math/test-double-scalb
FAIL: math/test-double-sincos
FAIL: math/test-double-sinh
FAIL: math/test-double-tgamma
FAIL: math/test-fenv-return
FAIL: math/test-fesetexcept
FAIL: math/test-fexcept
FAIL: math/test-float-atan2
FAIL: math/test-float-cabs
FAIL: math/test-float-ceil
FAIL: math/test-float-cosh
FAIL: math/test-float-erfc
FAIL: math/test-float-exp
FAIL: math/test-float-exp2
FAIL: math/test-float-fdim
FAIL: math/test-float-floor
FAIL: math/test-float-fmax
FAIL: math/test-float-frexp
FAIL: math/test-float-hypot
FAIL: math/test-float-lgamma
FAIL: math/test-float-log2p1
FAIL: math/test-float-pow
FAIL: math/test-float-remainder
FAIL: math/test-float-scalb
FAIL: math/test-float-sincos
FAIL: math/test-float-sinh
FAIL: math/test-float-tgamma
FAIL: math/test-float128-log2p1
FAIL: math/test-float32-atan2
FAIL: math/test-float32-cabs
FAIL: math/test-float32-ceil
FAIL: math/test-float32-cosh
FAIL: math/test-float32-erfc
FAIL: math/test-float32-exp
FAIL: math/test-float32-exp2
FAIL: math/test-float32-fdim
FAIL: math/test-float32-floor
FAIL: math/test-float32-fmax
FAIL: math/test-float32-frexp
FAIL: math/test-float32-hypot
FAIL: math/test-float32-lgamma
FAIL: math/test-float32-log2p1
FAIL: math/test-float32-pow
FAIL: math/test-float32-remainder
FAIL: math/test-float32-sincos
FAIL: math/test-float32-sinh
FAIL: math/test-float32-tgamma
FAIL: math/test-float32x-atan2
FAIL: math/test-float32x-ceil
FAIL: math/test-float32x-cosh
FAIL: math/test-float32x-erfc
FAIL: math/test-float32x-exp
FAIL: math/test-float32x-exp10
FAIL: math/test-float32x-exp2
FAIL: math/test-float32x-fdim
FAIL: math/test-float32x-floor
FAIL: math/test-float32x-fmax
FAIL: math/test-float32x-frexp
FAIL: math/test-float32x-hypot
FAIL: math/test-float32x-j1
FAIL: math/test-float32x-lgamma
FAIL: math/test-float32x-log2p1
FAIL: math/test-float32x-pow
FAIL: math/test-float32x-remainder
FAIL: math/test-float32x-sincos
FAIL: math/test-float32x-sinh
FAIL: math/test-float32x-tgamma
FAIL: math/test-float64-atan2
FAIL: math/test-float64-ceil
FAIL: math/test-float64-cosh
FAIL: math/test-float64-erfc
FAIL: math/test-float64-exp
FAIL: math/test-float64-exp10
FAIL: math/test-float64-exp2
FAIL: math/test-float64-fdim
FAIL: math/test-float64-floor
FAIL: math/test-float64-fmax
FAIL: math/test-float64-frexp
FAIL: math/test-float64-hypot
FAIL: math/test-float64-j1
FAIL: math/test-float64-lgamma
FAIL: math/test-float64-log2p1
FAIL: math/test-float64-pow
FAIL: math/test-float64-remainder
FAIL: math/test-float64-sincos
FAIL: math/test-float64-sinh
FAIL: math/test-float64-tgamma
FAIL: math/test-float64x-atan2
FAIL: math/test-float64x-ceil
FAIL: math/test-float64x-cosh
FAIL: math/test-float64x-erfc
FAIL: math/test-float64x-exp
FAIL: math/test-float64x-exp10
FAIL: math/test-float64x-exp2
FAIL: math/test-float64x-fdim
FAIL: math/test-float64x-floor
FAIL: math/test-float64x-fmax
FAIL: math/test-float64x-fpclassify
FAIL: math/test-float64x-frexp
FAIL: math/test-float64x-hypot
FAIL: math/test-float64x-isnan
FAIL: math/test-float64x-issignaling
FAIL: math/test-float64x-lgamma
FAIL: math/test-float64x-log2p1
FAIL: math/test-float64x-pow
FAIL: math/test-float64x-remainder
FAIL: math/test-float64x-sincos
FAIL: math/test-float64x-sinh
FAIL: math/test-float64x-tgamma
FAIL: math/test-floor-except-2
FAIL: math/test-ldouble-atan2
FAIL: math/test-ldouble-ceil
FAIL: math/test-ldouble-cosh
FAIL: math/test-ldouble-erfc
FAIL: math/test-ldouble-exp
FAIL: math/test-ldouble-exp10
FAIL: math/test-ldouble-exp2
FAIL: math/test-ldouble-fdim
FAIL: math/test-ldouble-floor
FAIL: math/test-ldouble-fmax
FAIL: math/test-ldouble-fpclassify
FAIL: math/test-ldouble-frexp
FAIL: math/test-ldouble-hypot
FAIL: math/test-ldouble-isnan
FAIL: math/test-ldouble-issignaling
FAIL: math/test-ldouble-lgamma
FAIL: math/test-ldouble-log2p1
FAIL: math/test-ldouble-pow
FAIL: math/test-ldouble-remainder
FAIL: math/test-ldouble-scalb
FAIL: math/test-ldouble-sincos
FAIL: math/test-ldouble-sinh
FAIL: math/test-ldouble-tgamma
FAIL: math/test-nearbyint-except
FAIL: misc/tst-misalign-clone
FAIL: nptl/tst-cancel21
FAIL: nptl/tst-cancel21-static
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/tst-canon-bz26341
FAIL: stdlib/tst-makecontext3
=== Summary of results ===
166 FAIL
4524 PASS
77 UNSUPPORTED
20 XFAIL
3 XPASS
Anything in particular you want to see? Do you want to create a separate bug for each distinct remaining issue?
@matoro :
Do you want to create a separate bug for each distinct remaining issue?
No, I think that would be too much (work and effort) for now. I'm afraid we will alreay have enough work at hand to keep it maintained and in a working state until near the end of the year.
To help us with that I'm in the process of setting up automatic cross-builds for glibc, binutils and gcc snapshots to get notified of build problems early on.
And it looks like I'm not too early with that, as something must have broken after https://github.com/linux-ia64/glibc-ia64/commit/3953b5b88f674d33675662e2e8d3a5f3cfda720c, because with https://snapshots.sourceware.org/glibc/trunk/2024-06-21_14-20_1718979601/src/glibc-2.39.9000-359-g5aa2f79691.tar.xz the build for ia64 is broken. I'll create a separate issue (#2) for that with all information I could find so far later the day.
I tried to build release/2.40/master-epic
branch, but it errors out with the following:
/usr/lib/gcc/ia64-unknown-linux-gnu/13/../../../../ia64-unknown-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-9999/work/build-ia64-ia64-unknown-linux-gnu-nptl/math/test-double-log1p.o: in function `logp1_test':
test-double-log1p.c:(.text+0x1022): undefined reference to `logp1'
/usr/lib/gcc/ia64-unknown-linux-gnu/13/../../../../ia64-unknown-linux-gnu/bin/ld: test-double-log1p.c:(.text+0x1122): undefined reference to `logp1'
/usr/lib/gcc/ia64-unknown-linux-gnu/13/../../../../ia64-unknown-linux-gnu/bin/ld: test-double-log1p.c:(.text+0x1222): undefined reference to `logp1'
/usr/lib/gcc/ia64-unknown-linux-gnu/13/../../../../ia64-unknown-linux-gnu/bin/ld: test-double-log1p.c:(.text+0x1322): undefined reference to `logp1'
/usr/lib/gcc/ia64-unknown-linux-gnu/13/../../../../ia64-unknown-linux-gnu/bin/ld: warning: -z relro ignored
collect2: error: ld returned 1 exit status
make[2]: *** [../Rules:237: /var/tmp/portage/sys-libs/glibc-9999/work/build-ia64-ia64-unknown-linux-gnu-nptl/math/test-double-log1p] Error 1
Repro with:
EGIT_OVERRIDE_REPO_GLIBC="https://github.com/linux-ia64/glibc-ia64" EGIT_OVERRIDE_BRANCH_GLIBC="release/2.40/master-epic" ../dotest.sh =sys-libs/glibc-9999
@matoro : Thanks for reporting. Strange, 2.40 built fine cross, see https://github.com/johnny-mnemonic/toolchain-autobuilds/actions/runs/10031301500/job/27721605313#step:4:118, unless that does not cover everything. But the logs show that logp1*
is in use and no problems during linking.
Just to know what gcc and binutils versions do you use? The toolchain cross-builds always use the latest snapshots of binutils, gcc and glibc (see https://github.com/johnny-mnemonic/toolchain-autobuilds/actions/runs/10031301500/job/27721605313#step:4:19), not sure if that makes a difference.
@matoro : Yeah, looks like the cross-builds don't cover that, as the log has no mentions of test-double-log1p.c
. Do any of the other new tests (for log2p1, log10p1, exp2m1 and exp10m1) build/link correctly (if they are build before the logp1 test)?
@matoro : If you still have the source, could you please post the source code in that created test "test-double-log1p.c"? I wonder if it makes use of those arch specific "-ulps" files. Because for ia64 there are no definitions for those new C23 functions and this seems to be the only difference to other arches so far. E.g. for alpha the logp1 relevant part of that file (sysdeps/alpha/fpu/libm-test-ulps
) looks like that:
[...]
Function: "logp1":
double: 1
float: 1
ldouble: 3
Function: "logp1_downward":
double: 2
float: 2
ldouble: 3
Function: "logp1_towardzero":
double: 2
float: 2
ldouble: 3
Function: "logp1_upward":
double: 2
float: 2
ldouble: 2
[...]
Looks like this is all that's in it:
$ cat latest-default/var/tmp/portage/sys-libs/glibc-9999/work/build-ia64-ia64-unknown-linux-gnu-nptl/math/test-double-log1p.c
#include <test-double.h>
#include <test-math-exceptions.h>
#include <test-math-errno.h>
#include <test-math-scalar.h>
#include <libm-test-log1p.c>
Just to avoid back-and-forth, here's a copy of the entire source and results: https://synapse.matoro.tk/_matrix/media/v3/download/synapse.matoro.tk/JtYhxqdIfbeEbNsTOuswivbR?allow_redirect=true
@matoro : Thanks for providing the tarball, I could now verify that the test executables for:
test-double-exp2m1
)test-double-exp10m1
)test-double-log10p1
)test-double-log2p1
)...are built and linked successfully. So it's not a general issue, but specific for "logp1". Also specific for this is that for all the other tests of the new C23 functions there exist function implementations for all supported data types. But for "logp1" there only exists the test implementation:
build-ia64-ia64-unknown-linux-gnu-nptl/math# ls *log2p1*
libm-test-log2p1.c s_log2p1f.os s_log2p1.os.d test-float32-log2p1.o.dt test-float-log2p1.c
s_log2p1.c s_log2p1f.os.d test-double-log2p1 test-float32x-log2p1.c test-float-log2p1.o
s_log2p1f128.c s_log2p1l.c test-double-log2p1.c test-float32x-log2p1.o test-float-log2p1.o.dt
s_log2p1f128.o s_log2p1l.o test-double-log2p1.o test-float32x-log2p1.o.dt test-ldouble-log2p1.c
s_log2p1f128.o.d s_log2p1l.o.d test-double-log2p1.o.dt test-float64-log2p1.c test-ldouble-log2p1.o
s_log2p1f128.os s_log2p1l.os test-float128-log2p1.c test-float64-log2p1.o test-ldouble-log2p1.o.dt
s_log2p1f128.os.d s_log2p1l.os.d test-float128-log2p1.o test-float64-log2p1.o.dt test-tgmath3-log2p1.c
s_log2p1f.c s_log2p1.o test-float128-log2p1.o.dt test-float64x-log2p1.c test-tgmath3-log2p1.o
s_log2p1f.o s_log2p1.o.d test-float32-log2p1.c test-float64x-log2p1.o test-tgmath3-log2p1.o.dt
s_log2p1f.o.d s_log2p1.os test-float32-log2p1.o test-float64x-log2p1.o.dt
build-ia64-ia64-unknown-linux-gnu-nptl/math# ls *logp1*
test-tgmath3-logp1.c test-tgmath3-logp1.o test-tgmath3-logp1.o.dt
No wonder it can't find the "logp1" symbol.
It must be related to the way it is implemented:
[...] 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.
...(from https://github.com/linux-ia64/glibc-ia64/commit/bb014f50c4a0c8d8db1ba5af55c104e430b5533d).
Well, at least a hint.
@johnny-mnemonic If we are just missing an implementation for log1p
, that shouldn't be that hard to do. I'll try to look at that later.
@lenticularis39 : ia64 has its own versions of "log1p":
sysdeps/ia64/fpu$ ls *log1p*
s_log1pf.S s_log1pl.S s_log1p.S w_log1p.c w_log1pf.c w_log1pl.c
And "logp1" should just be an alias for that IIUC (see https://github.com/linux-ia64/glibc-ia64/issues/1#issuecomment-2249107149). I think the problem lies in the way this is implemented. Joseph Meyers wrote later (in https://github.com/linux-ia64/glibc-ia64/commit/bb014f50c4a0c8d8db1ba5af55c104e430b5533d) that as there are vector versions of "log1p" for arm64 and x86_64 those needed to be handled differently:
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).
We need to compare the changes for arm64 and x86_64 with other arches to find the differences.
...also looking for *log1p*
in math
shows that the implementations are actually there:
build-ia64-ia64-unknown-linux-gnu-nptl/math# ls *log1p*
libm-test-log1p.c s_log1p.o test-float32x-log1p.c test-ldouble-log1p.o w_log1pf.o.d
s_log1pf128.o s_log1p.o.d test-float32x-log1p.o test-ldouble-log1p.o.dt w_log1pf.os
s_log1pf128.o.d s_log1p.os test-float32x-log1p.o.dt test-tgmath3-log1p.c w_log1pf.os.d
s_log1pf128.os s_log1p.os.d test-float64-log1p.c test-tgmath3-log1p.o w_log1pl.c
s_log1pf128.os.d test-double-log1p.c test-float64-log1p.o test-tgmath3-log1p.o.dt w_log1pl.o
s_log1pf.o test-double-log1p.o test-float64-log1p.o.dt w_log1p.c w_log1pl.o.d
s_log1pf.o.d test-double-log1p.o.dt test-float64x-log1p.c w_log1pf128.c w_log1pl.os
s_log1pf.os test-float128-log1p.c test-float64x-log1p.o w_log1pf128.o w_log1pl.os.d
s_log1pf.os.d test-float128-log1p.o test-float64x-log1p.o.dt w_log1pf128.o.d w_log1p.o
s_log1pl.o test-float128-log1p.o.dt test-float-log1p.c w_log1pf128.os w_log1p.o.d
s_log1pl.o.d test-float32-log1p.c test-float-log1p.o w_log1pf128.os.d w_log1p.os
s_log1pl.os test-float32-log1p.o test-float-log1p.o.dt w_log1pf.c w_log1p.os.d
s_log1pl.os.d test-float32-log1p.o.dt test-ldouble-log1p.c w_log1pf.o
I htink https://github.com/linux-ia64/glibc-ia64/commit/bb014f50c4a0c8d8db1ba5af55c104e430b5533d#diff-15bedff5ca9338cd36d5cac117fc32513aa32df0176bb700bad121e9c5e48b52R1149 does not detect correctly that ia64 has multiple versions for "log1p" as in _"matching more than one ALL_RMTEST line in a file testing multiple functions with the same inputs, when it assumes that the .inc file only has a single such line".
I saw a request to help test this, so I ran the test suite using Gentoo packaging. You can reproduce this on real hardware with:
These are run on kernel 6.6.32. Here are the results:
Here's a tarball with the complete build and detailed test logs.