* state of the ports
@ 2024-02-02 2:35 Andreas K. Huettel
2024-02-02 7:51 ` Xi Ruoyao
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Andreas K. Huettel @ 2024-02-02 2:35 UTC (permalink / raw)
To: libc-alpha
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
So... after all the testing gone into the release I thought I'd summarize a bit
for the list here - by sorting the glibc ports into "excellent", "good", "medium",
"bad", and "nobody even tried".
Feel free to correct my assessment... Most of the underlying info is on the
2.39 release wiki page.
Cheers,
Andreas
1. EXCELLENT
============
aarch64
- tests pass nearly everywhere
- on raspi, likely timeouts
arm-linux-gnueabi (soft-float)
arm-linux-gnueabihf (hard-float)
- one mystery test failure (elf/tst-align3)
loongarch64
- tests pass
powerpc64
powerpc64le
- tests pass
s390x
- tests pass
x86-64
- tests pass
x86-64 (x32)
- one expected failure, tests pass otherwise
2. GOOD
============
powerpc64
ppc 32bit hf
- one failure that indicates something broken (nptl/tst-thread-exit-clobber)
riscv64
- ~5 failures, but there may be timeouts among them
s390 (31bit)
- two failures due to gcc breakage (gmon/tst-gmon-pie*)
sparc
- ~5 failures (!)
x86 (32bit)
- in general tests pass
- there may be breakage on old hw (pentium2)
3. MEDIUM
============
ARC
- 11 failures
hppa2.0
- 12 failures (on ~20 year old hw! that's actually good)
4. BAD
============
Debian
- OK not really a port :) but it seems there are some machines where
broken Debian installs lead to massive amounts of FAIL
mips (o32)
- actually broken right now, it seems, the tests came too late
mips (n64)
- mostly math failures
riscv32
- 37 failures across the board
99. NOBODY TRIED
=================
alpha
c-sky
hppa1.1
m68k
microblaze
mips64 (N32)
niosii
openrisc
superh
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 2:35 state of the ports Andreas K. Huettel
@ 2024-02-02 7:51 ` Xi Ruoyao
2024-02-02 7:53 ` Xi Ruoyao
2024-02-04 7:37 ` Stafford Horne
2024-02-25 22:47 ` Mark Wielaard
2 siblings, 1 reply; 11+ messages in thread
From: Xi Ruoyao @ 2024-02-02 7:51 UTC (permalink / raw)
To: Andreas K. Huettel, libc-alpha
On Fri, 2024-02-02 at 03:35 +0100, Andreas K. Huettel wrote:
> mips (n64)
> - mostly math failures
They are some sort of 2 ulp vs expected 1 ulp things. I'm not yet sure
if they are hardware issues or Glibc bugs.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 7:51 ` Xi Ruoyao
@ 2024-02-02 7:53 ` Xi Ruoyao
2024-02-02 11:28 ` Florian Weimer
0 siblings, 1 reply; 11+ messages in thread
From: Xi Ruoyao @ 2024-02-02 7:53 UTC (permalink / raw)
To: Andreas K. Huettel, libc-alpha
On Fri, 2024-02-02 at 15:51 +0800, Xi Ruoyao wrote:
> On Fri, 2024-02-02 at 03:35 +0100, Andreas K. Huettel wrote:
> > mips (n64)
> > - mostly math failures
>
> They are some sort of 2 ulp vs expected 1 ulp things. I'm not yet sure
> if they are hardware issues or Glibc bugs.
Something like:
testing double (without inline functions)
Failure: Test: j0 (0x4.130e7p+4)
Result:
is: -1.0474906594151864e-04 -0x1.b759740016860p-14
should be: -1.0474906594151868e-04 -0x1.b759740016863p-14
difference: 4.0657581468206416e-20 0x1.8000000000000p-65
ulp : 3.0000
max.ulp : 2.0000
Maximal error of `j0'
is : 3 ulp
accepted: 2 ulp
Failure: Test: j0_downward (0xa.5b833p+4)
Result:
is: 1.4785400727226293e-05 0x1.f01da00ab51d1p-17
should be: 1.4785400727226283e-05 0x1.f01da00ab51cbp-17
difference: 1.0164395367051604e-20 0x1.8000000000000p-67
ulp : 6.0000
max.ulp : 5.0000
Maximal error of `j0_downward'
is : 6 ulp
accepted: 5 ulp
Failure: Test: j0_towardzero (0xa.5b833p+4)
Result:
is: 1.4785400727226271e-05 0x1.f01da00ab51c4p-17
should be: 1.4785400727226283e-05 0x1.f01da00ab51cbp-17
difference: 1.1858461261560204e-20 0x1.c000000000000p-67
ulp : 7.0000
max.ulp : 6.0000
Maximal error of `j0_towardzero'
is : 7 ulp
accepted: 6 ulp
Test suite completed:
212 test cases plus 208 tests for exception flags and
208 tests for errno executed.
6 errors occurred.
I'm really not an expert in numerical analysis. Any pointer to debug
such a thing further?
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 7:53 ` Xi Ruoyao
@ 2024-02-02 11:28 ` Florian Weimer
2024-02-02 21:40 ` Andreas K. Huettel
0 siblings, 1 reply; 11+ messages in thread
From: Florian Weimer @ 2024-02-02 11:28 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: Andreas K. Huettel, libc-alpha
* Xi Ruoyao:
> On Fri, 2024-02-02 at 15:51 +0800, Xi Ruoyao wrote:
>> On Fri, 2024-02-02 at 03:35 +0100, Andreas K. Huettel wrote:
>> > mips (n64)
>> > - mostly math failures
>>
>> They are some sort of 2 ulp vs expected 1 ulp things. I'm not yet sure
>> if they are hardware issues or Glibc bugs.
>
> Something like:
>
> testing double (without inline functions)
> Failure: Test: j0 (0x4.130e7p+4)
> Result:
> is: -1.0474906594151864e-04 -0x1.b759740016860p-14
> should be: -1.0474906594151868e-04 -0x1.b759740016863p-14
> difference: 4.0657581468206416e-20 0x1.8000000000000p-65
> ulp : 3.0000
> max.ulp : 2.0000
> Maximal error of `j0'
> is : 3 ulp
> accepted: 2 ulp
> Failure: Test: j0_downward (0xa.5b833p+4)
> Result:
> is: 1.4785400727226293e-05 0x1.f01da00ab51d1p-17
> should be: 1.4785400727226283e-05 0x1.f01da00ab51cbp-17
> difference: 1.0164395367051604e-20 0x1.8000000000000p-67
> ulp : 6.0000
> max.ulp : 5.0000
> Maximal error of `j0_downward'
> is : 6 ulp
> accepted: 5 ulp
> Failure: Test: j0_towardzero (0xa.5b833p+4)
> Result:
> is: 1.4785400727226271e-05 0x1.f01da00ab51c4p-17
> should be: 1.4785400727226283e-05 0x1.f01da00ab51cbp-17
> difference: 1.1858461261560204e-20 0x1.c000000000000p-67
> ulp : 7.0000
> max.ulp : 6.0000
> Maximal error of `j0_towardzero'
> is : 7 ulp
> accepted: 6 ulp
>
> Test suite completed:
> 212 test cases plus 208 tests for exception flags and
> 208 tests for errno executed.
> 6 errors occurred.
>
> I'm really not an expert in numerical analysis. Any pointer to debug
> such a thing further?
I think these are well within the bounds that other ports accept. If
there are genuine bugs, the results are off by thousands or millions of
ulps.
Thanks,
Florian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 11:28 ` Florian Weimer
@ 2024-02-02 21:40 ` Andreas K. Huettel
2024-02-22 17:11 ` Xi Ruoyao
0 siblings, 1 reply; 11+ messages in thread
From: Andreas K. Huettel @ 2024-02-02 21:40 UTC (permalink / raw)
To: Xi Ruoyao, Florian Weimer; +Cc: libc-alpha
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
Am Freitag, 2. Februar 2024, 12:28:45 CET schrieb Florian Weimer:
> * Xi Ruoyao:
>
> > On Fri, 2024-02-02 at 15:51 +0800, Xi Ruoyao wrote:
> >> On Fri, 2024-02-02 at 03:35 +0100, Andreas K. Huettel wrote:
> >> > mips (n64)
> >> > - mostly math failures
> >>
> >> They are some sort of 2 ulp vs expected 1 ulp things. I'm not yet sure
> >> if they are hardware issues or Glibc bugs.
> >
> > Something like:
> >
> > is : 3 ulp
> > accepted: 2 ulp
[..]
> >
> > I'm really not an expert in numerical analysis. Any pointer to debug
> > such a thing further?
That looks like it can be "fixed" by regenerate-ulps, not like a real bug.
So the real number of fails is likely smaller indeed. \o/
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 2:35 state of the ports Andreas K. Huettel
2024-02-02 7:51 ` Xi Ruoyao
@ 2024-02-04 7:37 ` Stafford Horne
2024-02-04 11:40 ` Andreas K. Huettel
2024-02-25 22:47 ` Mark Wielaard
2 siblings, 1 reply; 11+ messages in thread
From: Stafford Horne @ 2024-02-04 7:37 UTC (permalink / raw)
To: Andreas K. Huettel; +Cc: libc-alpha
On Fri, Feb 02, 2024 at 03:35:04AM +0100, Andreas K. Huettel wrote:
> So... after all the testing gone into the release I thought I'd summarize a bit
> for the list here - by sorting the glibc ports into "excellent", "good", "medium",
> "bad", and "nobody even tried".
>
> Feel free to correct my assessment... Most of the underlying info is on the
> 2.39 release wiki page.
>
> Cheers,
> Andreas
>
>
> 1. EXCELLENT
> ============
>
> aarch64
> - tests pass nearly everywhere
> - on raspi, likely timeouts
>
> arm-linux-gnueabi (soft-float)
> arm-linux-gnueabihf (hard-float)
> - one mystery test failure (elf/tst-align3)
>
> loongarch64
> - tests pass
>
> powerpc64
> powerpc64le
> - tests pass
>
> s390x
> - tests pass
>
> x86-64
> - tests pass
>
> x86-64 (x32)
> - one expected failure, tests pass otherwise
>
>
> 2. GOOD
> ============
>
> powerpc64
> ppc 32bit hf
> - one failure that indicates something broken (nptl/tst-thread-exit-clobber)
>
> riscv64
> - ~5 failures, but there may be timeouts among them
>
> s390 (31bit)
> - two failures due to gcc breakage (gmon/tst-gmon-pie*)
>
> sparc
> - ~5 failures (!)
>
> x86 (32bit)
> - in general tests pass
> - there may be breakage on old hw (pentium2)
>
>
> 3. MEDIUM
> ============
>
> ARC
> - 11 failures
>
> hppa2.0
> - 12 failures (on ~20 year old hw! that's actually good)
>
>
> 4. BAD
> ============
>
> Debian
> - OK not really a port :) but it seems there are some machines where
> broken Debian installs lead to massive amounts of FAIL
>
> mips (o32)
> - actually broken right now, it seems, the tests came too late
>
> mips (n64)
> - mostly math failures
>
> riscv32
> - 37 failures across the board
>
>
> 99. NOBODY TRIED
> =================
>
> alpha
>
> c-sky
>
> hppa1.1
>
> m68k
>
> microblaze
>
> mips64 (N32)
>
> niosii
>
> openrisc
Hello,
I it unfortunate that openrisc ended up in NOBODY TRIED, I usually try to test
the port for each release. However, this time the testing mail slipped through
my mail filters.
Note, during "glibc 2.36 - Machine testing." Carlos CCed each maintainer on the
announcement mail. This makes it easier for us maintainers to know we need to
take action.
Can maintainers be CCed on these announcements going forward?
For 2.39, I see the main only went to the list.
-Stafford
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-04 7:37 ` Stafford Horne
@ 2024-02-04 11:40 ` Andreas K. Huettel
0 siblings, 0 replies; 11+ messages in thread
From: Andreas K. Huettel @ 2024-02-04 11:40 UTC (permalink / raw)
To: Stafford Horne; +Cc: libc-alpha
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
>
> Hello,
>
> I it unfortunate that openrisc ended up in NOBODY TRIED, I usually try to test
> the port for each release. However, this time the testing mail slipped through
> my mail filters.
>
> Note, during "glibc 2.36 - Machine testing." Carlos CCed each maintainer on the
> announcement mail. This makes it easier for us maintainers to know we need to
> take action.
>
> Can maintainers be CCed on these announcements going forward?
>
> For 2.39, I see the main only went to the list.
Sorry about that, I promise to do better next time.
Best
-Andreas
>
> -Stafford
>
>
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 21:40 ` Andreas K. Huettel
@ 2024-02-22 17:11 ` Xi Ruoyao
2024-02-22 20:30 ` Andreas K. Huettel
0 siblings, 1 reply; 11+ messages in thread
From: Xi Ruoyao @ 2024-02-22 17:11 UTC (permalink / raw)
To: Andreas K. Huettel, Florian Weimer; +Cc: libc-alpha
On Fri, 2024-02-02 at 22:40 +0100, Andreas K. Huettel wrote:
> Am Freitag, 2. Februar 2024, 12:28:45 CET schrieb Florian Weimer:
> > * Xi Ruoyao:
> >
> > > On Fri, 2024-02-02 at 15:51 +0800, Xi Ruoyao wrote:
> > > > On Fri, 2024-02-02 at 03:35 +0100, Andreas K. Huettel wrote:
> > > > > mips (n64)
> > > > > - mostly math failures
> > > >
> > > > They are some sort of 2 ulp vs expected 1 ulp things. I'm not yet sure
> > > > if they are hardware issues or Glibc bugs.
> > >
> > > Something like:
> > >
> > > is : 3 ulp
> > > accepted: 2 ulp
> [..]
> > >
> > > I'm really not an expert in numerical analysis. Any pointer to debug
> > > such a thing further?
>
> That looks like it can be "fixed" by regenerate-ulps, not like a real bug.
>
> So the real number of fails is likely smaller indeed. \o/
An update on this: most of the failures were caused by my hardware:the
mips64r2 specification says FP madd should be unfused but the Loongson
hardware implements it as fused. Passing the correct -march option to
GCC can fix them. I'll note this in the wiki...
OTOH some ulps indeed needs an update and the updated values seem same
as the other ports using the generic math implementation (RISC-V and
LoongArch) :
--- ../sysdeps/mips/mips64/libm-test-ulps 2024-02-23 00:56:46.428819912 +0800
+++ /home/xry111/git-repos/glibc-build/math/NewUlps 2024-02-23 00:59:29.085565020 +0800
@@ -1066,17 +1066,17 @@
ldouble: 1
Function: "j0":
-double: 2
+double: 3
float: 9
ldouble: 2
Function: "j0_downward":
-double: 5
+double: 6
float: 9
ldouble: 9
Function: "j0_towardzero":
-double: 6
+double: 7
float: 9
ldouble: 9
@@ -1146,6 +1146,7 @@
ldouble: 8
Function: "log":
+double: 1
float: 1
ldouble: 1
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-22 17:11 ` Xi Ruoyao
@ 2024-02-22 20:30 ` Andreas K. Huettel
0 siblings, 0 replies; 11+ messages in thread
From: Andreas K. Huettel @ 2024-02-22 20:30 UTC (permalink / raw)
To: Florian Weimer, libc-alpha; +Cc: Xi Ruoyao
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
>
> OTOH some ulps indeed needs an update and the updated values seem same
> as the other ports using the generic math implementation (RISC-V and
> LoongArch) :
Thank you! Pushed to master and 2.39 branch.
>
> --- ../sysdeps/mips/mips64/libm-test-ulps 2024-02-23 00:56:46.428819912 +0800
> +++ /home/xry111/git-repos/glibc-build/math/NewUlps 2024-02-23 00:59:29.085565020 +0800
> @@ -1066,17 +1066,17 @@
> ldouble: 1
>
> Function: "j0":
> -double: 2
> +double: 3
> float: 9
> ldouble: 2
>
> Function: "j0_downward":
> -double: 5
> +double: 6
> float: 9
> ldouble: 9
>
> Function: "j0_towardzero":
> -double: 6
> +double: 7
> float: 9
> ldouble: 9
>
> @@ -1146,6 +1146,7 @@
> ldouble: 8
>
> Function: "log":
> +double: 1
> float: 1
> ldouble: 1
>
>
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-02 2:35 state of the ports Andreas K. Huettel
2024-02-02 7:51 ` Xi Ruoyao
2024-02-04 7:37 ` Stafford Horne
@ 2024-02-25 22:47 ` Mark Wielaard
2024-02-26 12:44 ` Adhemerval Zanella Netto
2 siblings, 1 reply; 11+ messages in thread
From: Mark Wielaard @ 2024-02-25 22:47 UTC (permalink / raw)
To: Andreas K. Huettel; +Cc: libc-alpha
Hi,
On Fri, Feb 02, 2024 at 03:35:04AM +0100, Andreas K. Huettel wrote:
> So... after all the testing gone into the release I thought I'd
> summarize a bit for the list here - by sorting the glibc ports into
> "excellent", "good", "medium", "bad", and "nobody even tried".
We have several buildbots at builder.sourceware.org for glibc which
probably should start sending build failure emails when things break.
https://builder.sourceware.org/buildbot/#/builders?tags=glibc
> 1. EXCELLENT
> ============
>
> aarch64
> - tests pass nearly everywhere
> - on raspi, likely timeouts
https://builder.sourceware.org/buildbot/#/builders/glibc-debian-arm64
Used to have some tests time out, but since we are running with
TIMEOUTFACTOR=4 is all green:
4807 PASS
22 UNSUPPORTED
16 XFAIL
2 XPASS
> powerpc64
> powerpc64le
> - tests pass
https://builder.sourceware.org/buildbot/#/builders/glibc-debian-ppc64
https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-ppc64le
We only do a make subdirs=elf check but those all pass:
glibc-debian-ppc64:
341 PASS
5 UNSUPPORTED
2 XPASS
glibc-fedora-ppc64le:
338 PASS
2 UNSUPPORTED
2 XPASS
> s390x
> - tests pass
https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-s390x
Likewise, just subdirs=elf:
336 PASS
2 UNSUPPORTED
2 XPASS
For ppc64, ppc64le and s390x we could run a different subset if that
is more useful. The issue really is the nptl subdir, which just takes
a very long time (because it doesn't run any test in parallel?)
> x86-64
> - tests pass
Fully green on glibc-fedora-x86_64
https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-x86_64
4945 PASS
274 UNSUPPORTED
16 XFAIL
4 XPASS
But on glibc-debian-testing-x86_64 and glibc-rawhide-x86_64 it
occassionally sees one FAIL: elf/tst-audit10 which times out even with
TIMEOUTFACTOR=4
> riscv64
> - ~5 failures, but there may be timeouts among them
https://builder.sourceware.org/buildbot/#/builders/glibc-ubuntu-riscv
With TIMEOUTFACTOR=4 there are no (timeout) failures anymore.
4699 PASS
24 UNSUPPORTED
16 XFAIL
2 XPASS
This is the slowest of them all (takes 2 hours 15 minutes to 3 hours,
depending on how good the ccache is). But we have multiple riscv
boards now thanks to StarFive and one of them is dedicated to glibc.
> sparc
> - ~5 failures (!)
Seeing even more failures:
9 FAIL
4725 PASS
23 UNSUPPORTED
17 XFAIL
2 XPASS
FAIL: elf/tst-audit18
FAIL: elf/tst-pldd
FAIL: elf/tst-ptrguard1
FAIL: math/test-float64x-float128-mul
FAIL: nptl/tst-mutex9
FAIL: nptl/tst-oddstacklimit
FAIL: posix/tst-spawn7-pidfd
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/tst-setcontext2
> x86 (32bit)
> - in general tests pass
> - there may be breakage on old hw (pentium2)
Really a i386 VM on x86_64:
https://builder.sourceware.org/buildbot/#/builders/glibc-debian-i386
4851 PASS
40 UNSUPPORTED
16 XFAIL
6 XPASS
Cheers,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: state of the ports
2024-02-25 22:47 ` Mark Wielaard
@ 2024-02-26 12:44 ` Adhemerval Zanella Netto
0 siblings, 0 replies; 11+ messages in thread
From: Adhemerval Zanella Netto @ 2024-02-26 12:44 UTC (permalink / raw)
To: Mark Wielaard, Andreas K. Huettel; +Cc: libc-alpha
On 25/02/24 19:47, Mark Wielaard wrote:
> Hi,
>
> On Fri, Feb 02, 2024 at 03:35:04AM +0100, Andreas K. Huettel wrote:
>> So... after all the testing gone into the release I thought I'd
>> summarize a bit for the list here - by sorting the glibc ports into
>> "excellent", "good", "medium", "bad", and "nobody even tried".
>
> We have several buildbots at builder.sourceware.org for glibc which
> probably should start sending build failure emails when things break.
> https://builder.sourceware.org/buildbot/#/builders?tags=glibc
It would be really helpful to proper document this instead of just throwing
a comment on https://sourceware.org/glibc/wiki/Buildbot saying the current
information is outdated. The wiki the main source of developer information
and I don't think linking to a blog post if the best way to document it.
And although the buildbot is a good improvement for glibc development,
this does seems like disjoint initiative that did not get much feedback
from glibc community and it is not really tied to current practice.
On the weekly call [1], we focus most of patchwork [2] results, which has
results for pre-commit buildbot setup by RedHat and extended by Linaro
for ARM. And on each release and on the following weeks, we check and
discuss the release wiki information to check for potential regressions
and such. Joseph also keeps a buildbot using build-many-glibcs.py to keep
track of build for all supported architectures [4].
So I personally think it would be more valuable to hook the buildbots on
the pre-commit CI instead of doing pos-commit checks.
[1] https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
[2] https://patchwork.sourceware.org/project/glibc/list/
[3] https://sourceware.org/glibc/wiki/Release/2.39
[4] https://sourceware.org/pipermail/libc-testresults/
>
>> 1. EXCELLENT
>> ============
>>
>> aarch64
>> - tests pass nearly everywhere
>> - on raspi, likely timeouts
>
> https://builder.sourceware.org/buildbot/#/builders/glibc-debian-arm64
> Used to have some tests time out, but since we are running with
> TIMEOUTFACTOR=4 is all green:
>
> 4807 PASS
> 22 UNSUPPORTED
> 16 XFAIL
> 2 XPASS
>
>> powerpc64
>> powerpc64le
>> - tests pass
>
> https://builder.sourceware.org/buildbot/#/builders/glibc-debian-ppc64
> https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-ppc64le
>
> We only do a make subdirs=elf check but those all pass:
>
> glibc-debian-ppc64:
> 341 PASS
> 5 UNSUPPORTED
> 2 XPASS
>
> glibc-fedora-ppc64le:
> 338 PASS
> 2 UNSUPPORTED
> 2 XPASS
>
>> s390x
>> - tests pass
>
> https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-s390x
> Likewise, just subdirs=elf:
>
> 336 PASS
> 2 UNSUPPORTED
> 2 XPASS
>
> For ppc64, ppc64le and s390x we could run a different subset if that
> is more useful. The issue really is the nptl subdir, which just takes
> a very long time (because it doesn't run any test in parallel?)
>
>> x86-64
>> - tests pass
>
> Fully green on glibc-fedora-x86_64
> https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-x86_64
>
> 4945 PASS
> 274 UNSUPPORTED
> 16 XFAIL
> 4 XPASS
>
> But on glibc-debian-testing-x86_64 and glibc-rawhide-x86_64 it
> occassionally sees one FAIL: elf/tst-audit10 which times out even with
> TIMEOUTFACTOR=4
>
>> riscv64
>> - ~5 failures, but there may be timeouts among them
>
> https://builder.sourceware.org/buildbot/#/builders/glibc-ubuntu-riscv
>
> With TIMEOUTFACTOR=4 there are no (timeout) failures anymore.
>
> 4699 PASS
> 24 UNSUPPORTED
> 16 XFAIL
> 2 XPASS
>
> This is the slowest of them all (takes 2 hours 15 minutes to 3 hours,
> depending on how good the ccache is). But we have multiple riscv
> boards now thanks to StarFive and one of them is dedicated to glibc.
>
>> sparc
>> - ~5 failures (!)
>
> Seeing even more failures:
>
> 9 FAIL
> 4725 PASS
> 23 UNSUPPORTED
> 17 XFAIL
> 2 XPASS
>
> FAIL: elf/tst-audit18
> FAIL: elf/tst-pldd
> FAIL: elf/tst-ptrguard1
> FAIL: math/test-float64x-float128-mul
> FAIL: nptl/tst-mutex9
> FAIL: nptl/tst-oddstacklimit
> FAIL: posix/tst-spawn7-pidfd
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/tst-setcontext2
>
>> x86 (32bit)
>> - in general tests pass
>> - there may be breakage on old hw (pentium2)
>
> Really a i386 VM on x86_64:
> https://builder.sourceware.org/buildbot/#/builders/glibc-debian-i386
>
> 4851 PASS
> 40 UNSUPPORTED
> 16 XFAIL
> 6 XPASS
>
> Cheers,
>
> Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-02-26 12:44 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-02 2:35 state of the ports Andreas K. Huettel
2024-02-02 7:51 ` Xi Ruoyao
2024-02-02 7:53 ` Xi Ruoyao
2024-02-02 11:28 ` Florian Weimer
2024-02-02 21:40 ` Andreas K. Huettel
2024-02-22 17:11 ` Xi Ruoyao
2024-02-22 20:30 ` Andreas K. Huettel
2024-02-04 7:37 ` Stafford Horne
2024-02-04 11:40 ` Andreas K. Huettel
2024-02-25 22:47 ` Mark Wielaard
2024-02-26 12:44 ` Adhemerval Zanella Netto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).