| Message ID | alpine.DEB.2.21.2407111353220.38148@angie.orcam.me.uk |
|---|---|
| State | New |
| Headers | show |
| Series | nptl: Fix issues with tst-sem11 and tst-sem12 tests | expand |
On 11/07/24 10:17, Maciej W. Rozycki wrote: > From: Maciej W. Rozycki <macro@redhat.com> > > Fix an issue with commit 2af4e3e5668f ("Test of semaphores.") by making > the tst-sem11 and tst-sem12 tests use the test driver, preventing them > from ever causing testing to hang forever and never complete, such as > currently happening with the 'mips-linux-gnu' (o32 ABI) target. Adjust > the name of the PREPARE macro, which clashes with the interpretation of > its presence by the test driver, by using a TF_ prefix in reference to > the name of the 'tf' function. LGTM, thanks. I don't see this issues with mipsel-linux-gnu on cfarm23. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > nptl/tst-sem11.c | 8 +++++--- > nptl/tst-sem12.c | 2 +- > 2 files changed, 6 insertions(+), 4 deletions(-) > > glibc-tst-sem11-test-driver.diff > Index: glibc/nptl/tst-sem11.c > =================================================================== > --- glibc.orig/nptl/tst-sem11.c > +++ glibc/nptl/tst-sem11.c > @@ -29,15 +29,15 @@ > static void * > tf (void *arg) > { > -#ifdef PREPARE > - PREPARE > +#ifdef TF_PREPARE > + TF_PREPARE > #endif > SEM_WAIT (arg); > return NULL; > } > > int > -main (void) > +do_test (void) > { > int tries = 5; > pthread_t th; > @@ -101,3 +101,5 @@ main (void) > > return 0; > } > + > +#include <support/test-driver.c> > Index: glibc/nptl/tst-sem12.c > =================================================================== > --- glibc.orig/nptl/tst-sem12.c > +++ glibc/nptl/tst-sem12.c > @@ -20,7 +20,7 @@ > #include <sys/time.h> > > > -#define PREPARE \ > +#define TF_PREPARE \ > struct timespec ts; \ > struct timeval tv; \ > gettimeofday (&tv, NULL); \
On Thu, 11 Jul 2024, Adhemerval Zanella Netto wrote: > > Fix an issue with commit 2af4e3e5668f ("Test of semaphores.") by making > > the tst-sem11 and tst-sem12 tests use the test driver, preventing them > > from ever causing testing to hang forever and never complete, such as > > currently happening with the 'mips-linux-gnu' (o32 ABI) target. Adjust > > the name of the PREPARE macro, which clashes with the interpretation of > > its presence by the test driver, by using a TF_ prefix in reference to > > the name of the 'tf' function. > > LGTM, thanks. I don't see this issues with mipsel-linux-gnu on cfarm23. What type of machine is cfarm23? The target in question runs Linux version 5.18.0-rc2, slightly out of date. Also the endianness is big. I don't know if either observation matters. Also the CPU is a 74Kf, an implementation of the MIPS32r2 ISA, running with the Malta platform (real hardware). As much as I'd love to investigate this further I have to defer it to the unspecified future. Results are not thrilling with the target overall: === Summary of results === 229 FAIL 4229 PASS 84 UNSUPPORTED 17 XFAIL 2 XPASS of which 90 failures in nptl/. There may be issues with the compiler as well (GCC 13.0.0 20221118). Thank you for your review. Maciej
On 11/07/24 11:54, Maciej W. Rozycki wrote: > On Thu, 11 Jul 2024, Adhemerval Zanella Netto wrote: > >>> Fix an issue with commit 2af4e3e5668f ("Test of semaphores.") by making >>> the tst-sem11 and tst-sem12 tests use the test driver, preventing them >>> from ever causing testing to hang forever and never complete, such as >>> currently happening with the 'mips-linux-gnu' (o32 ABI) target. Adjust >>> the name of the PREPARE macro, which clashes with the interpretation of >>> its presence by the test driver, by using a TF_ prefix in reference to >>> the name of the 'tf' function. >> >> LGTM, thanks. I don't see this issues with mipsel-linux-gnu on cfarm23. > > What type of machine is cfarm23? The cpuinfo reports a 'Cavium Octeon II V0.1', supporting 'mips2 mips3 mips4 mips5 mips64r2'; and the kernel is 4.1.4. > > The target in question runs Linux version 5.18.0-rc2, slightly out of > date. Also the endianness is big. I don't know if either observation > matters. Also the CPU is a 74Kf, an implementation of the MIPS32r2 ISA, > running with the Malta platform (real hardware). As much as I'd love to > investigate this further I have to defer it to the unspecified future. > > Results are not thrilling with the target overall: > > === Summary of results === > 229 FAIL > 4229 PASS > 84 UNSUPPORTED > 17 XFAIL > 2 XPASS > > of which 90 failures in nptl/. There may be issues with the compiler as > well (GCC 13.0.0 20221118). > > Thank you for your review. Andreas has reported similar issues on 2.39 [1] and the last time I did a full check on mips using cfarm was for 2.30 [2]. Joseph also did some runs for the other releases with mixed results as well. [1] https://sourceware.org/glibc/wiki/Release/2.39#MIPS_.2832-bit.2C_O32.29 [2] https://sourceware.org/glibc/wiki/Release/2.30#MIPS
Am Donnerstag, 11. Juli 2024, 19:40:57 MESZ schrieb Adhemerval Zanella Netto: > > On 11/07/24 11:54, Maciej W. Rozycki wrote: > > On Thu, 11 Jul 2024, Adhemerval Zanella Netto wrote: > > [...] > >> > >> LGTM, thanks. I don't see this issues with mipsel-linux-gnu on cfarm23. So far I haven't heard about any hangs on mips either. Anyway, pushed both to make sure they are in the release. > > === Summary of results === > > 229 FAIL > > 4229 PASS > > 84 UNSUPPORTED > > 17 XFAIL > > 2 XPASS > > > > of which 90 failures in nptl/. There may be issues with the compiler as > > well (GCC 13.0.0 20221118). What's the OS of the machine? If it's debian it could be something similar to https://sourceware.org/pipermail/libc-alpha/2024-January/154302.html see also [1] below ... > > > > Thank you for your review. > > Andreas has reported similar issues on 2.39 [1] and the last time I did a > full check on mips using cfarm was for 2.30 [2]. Joseph also did some > runs for the other releases with mixed results as well. > > [1] https://sourceware.org/glibc/wiki/Release/2.39#MIPS_.2832-bit.2C_O32.29 > [2] https://sourceware.org/glibc/wiki/Release/2.30#MIPS >
On 12/07/24 15:46, Andreas K. Huettel wrote: > Am Donnerstag, 11. Juli 2024, 19:40:57 MESZ schrieb Adhemerval Zanella Netto: >> >> On 11/07/24 11:54, Maciej W. Rozycki wrote: >>> On Thu, 11 Jul 2024, Adhemerval Zanella Netto wrote: >>> > [...] >>>> >>>> LGTM, thanks. I don't see this issues with mipsel-linux-gnu on cfarm23. > > So far I haven't heard about any hangs on mips either. > > Anyway, pushed both to make sure they are in the release. > >>> === Summary of results === >>> 229 FAIL >>> 4229 PASS >>> 84 UNSUPPORTED >>> 17 XFAIL >>> 2 XPASS >>> >>> of which 90 failures in nptl/. There may be issues with the compiler as >>> well (GCC 13.0.0 20221118). > > What's the OS of the machine? If it's debian it could be something similar to > https://sourceware.org/pipermail/libc-alpha/2024-January/154302.html > see also [1] below ... Indeed, usually for glibc testing I copy the required gcc libs (libgcc_s.so and libstdc++.so) to the builddir to avoid such issues.
On Fri, 12 Jul 2024, Andreas K. Huettel wrote: > > > === Summary of results === > > > 229 FAIL > > > 4229 PASS > > > 84 UNSUPPORTED > > > 17 XFAIL > > > 2 XPASS > > > > > > of which 90 failures in nptl/. There may be issues with the compiler as > > > well (GCC 13.0.0 20221118). > > What's the OS of the machine? If it's debian it could be something similar to > https://sourceware.org/pipermail/libc-alpha/2024-January/154302.html > see also [1] below ... What machine, the host machine or the target one? I think the host machine should not matter, it's a POWER9 box anyway. The target toolchain is built from scratch the usual way: by bootstrapping native POWER9 GCC first and then using it along with target GCC, once available, to build target binutils, Linux headers, glibc headers, initial GCC, glibc, final GCC, final glibc, gdb, gdbserver, with bits installed in the sysroot as required. It's no different from my other setups, such as the RISC-V one. The target has a bare minimum installed really: there are working SSH and NTP daemons (the latter to make sure NFS timestamps don't go out of sync), bash, a bunch of utilities. It netboots with an NFS root. The build directory is identity-mapped via another NFS mount for the test wrapper to work, with the attribute cache disabled of course. There have been 45 compilation failures like this: .../math/test-tgmath3-atan2.c: In function 'test_atan2_84': .../math/test-tgmath3-atan2.c:903:59: error: conflicting types for 'var__Float32x'; have 'double' 903 | extern typeof (atan2 (vol_var__Float32x, vol_var_char)) var__Float32x__attribute__ ((unused)); | ^~~~~~~~~~~~~ .../math/test-tgmath3-atan2.c:855:64: note: previous declaration of 'var__Float32x' with type '_Float32x' 855 | extern typeof (atan2 (vol_var__Float32x, vol_var__Float32x)) var__Float32x __attribute__ ((unused)); | ^~~~~~~~~~~~~ This is obviously something wrong on the glibc side. Then 103 failures have been test execution timeouts. So the tests either genuinely hang, such as these mentioned here, or I need to set TIMEOUTFACTOR; something to check with the next run perhaps, although the superscalar, out-of-order 74Kf@950MHz is rather fast, so I suspect that won't change results much if at all. Then 9 have failed with a segmentation fault and further 3 with an abort. This gives us 160 out of 229 failures. For the rest I'd have to go through .out files by hand to see what happened there; skimming over it's all kinds of issues. > > Andreas has reported similar issues on 2.39 [1] and the last time I did a > > full check on mips using cfarm was for 2.30 [2]. Joseph also did some > > runs for the other releases with mixed results as well. > > > > [1] https://sourceware.org/glibc/wiki/Release/2.39#MIPS_.2832-bit.2C_O32.29 > > [2] https://sourceware.org/glibc/wiki/Release/2.30#MIPS Well, that doesn't tell me anything beyond that there were failures. Maciej
On 13/07/24 03:37, Maciej W. Rozycki wrote: > On Fri, 12 Jul 2024, Andreas K. Huettel wrote: > >>>> === Summary of results === >>>> 229 FAIL >>>> 4229 PASS >>>> 84 UNSUPPORTED >>>> 17 XFAIL >>>> 2 XPASS >>>> >>>> of which 90 failures in nptl/. There may be issues with the compiler as >>>> well (GCC 13.0.0 20221118). >> >> What's the OS of the machine? If it's debian it could be something similar to >> https://sourceware.org/pipermail/libc-alpha/2024-January/154302.html >> see also [1] below ... > > What machine, the host machine or the target one? > > I think the host machine should not matter, it's a POWER9 box anyway. > The target toolchain is built from scratch the usual way: by bootstrapping > native POWER9 GCC first and then using it along with target GCC, once > available, to build target binutils, Linux headers, glibc headers, initial > GCC, glibc, final GCC, final glibc, gdb, gdbserver, with bits installed in > the sysroot as required. It's no different from my other setups, such as > the RISC-V one. > > The target has a bare minimum installed really: there are working SSH and > NTP daemons (the latter to make sure NFS timestamps don't go out of sync), > bash, a bunch of utilities. It netboots with an NFS root. The build > directory is identity-mapped via another NFS mount for the test wrapper to > work, with the attribute cache disabled of course. > > There have been 45 compilation failures like this: > > .../math/test-tgmath3-atan2.c: In function 'test_atan2_84': > .../math/test-tgmath3-atan2.c:903:59: error: conflicting types for 'var__Float32x'; have 'double' > 903 | extern typeof (atan2 (vol_var__Float32x, vol_var_char)) var__Float32x__attribute__ ((unused)); > | ^~~~~~~~~~~~~ > .../math/test-tgmath3-atan2.c:855:64: note: previous declaration of 'var__Float32x' with type '_Float32x' > 855 | extern typeof (atan2 (vol_var__Float32x, vol_var__Float32x)) var__Float32x __attribute__ ((unused)); > | ^~~~~~~~~~~~~ > Which gcc version are you using? I recall that we saw some issues on some targets when _Float32x was added, but I didn't see any build failures on master with recent gcc. I think we still might have some issues with older gcc trying to build recent glibc, I fixed some issues on some targets but I did check all of them. > This is obviously something wrong on the glibc side. Then 103 failures > have been test execution timeouts. So the tests either genuinely hang, > such as these mentioned here, or I need to set TIMEOUTFACTOR; something to > check with the next run perhaps, although the superscalar, out-of-order > 74Kf@950MHz is rather fast, so I suspect that won't change results much if > at all. Then 9 have failed with a segmentation fault and further 3 with > an abort. This gives us 160 out of 229 failures. > > For the rest I'd have to go through .out files by hand to see what > happened there; skimming over it's all kinds of issues. These seems to be real issues indeed. > >>> Andreas has reported similar issues on 2.39 [1] and the last time I did a >>> full check on mips using cfarm was for 2.30 [2]. Joseph also did some >>> runs for the other releases with mixed results as well. >>> >>> [1] https://sourceware.org/glibc/wiki/Release/2.39#MIPS_.2832-bit.2C_O32.29 >>> [2] https://sourceware.org/glibc/wiki/Release/2.30#MIPS > > Well, that doesn't tell me anything beyond that there were failures. Yes, unfortunately on old releases we did not added additional details per failures to help track down the possible issues. We started to document this better on recent ones.
On Mon, 15 Jul 2024, Adhemerval Zanella Netto wrote: > >>>> of which 90 failures in nptl/. There may be issues with the compiler as > >>>> well (GCC 13.0.0 20221118). [...] > > There have been 45 compilation failures like this: > > > > .../math/test-tgmath3-atan2.c: In function 'test_atan2_84': > > .../math/test-tgmath3-atan2.c:903:59: error: conflicting types for 'var__Float32x'; have 'double' > > 903 | extern typeof (atan2 (vol_var__Float32x, vol_var_char)) var__Float32x__attribute__ ((unused)); > > | ^~~~~~~~~~~~~ > > .../math/test-tgmath3-atan2.c:855:64: note: previous declaration of 'var__Float32x' with type '_Float32x' > > 855 | extern typeof (atan2 (vol_var__Float32x, vol_var__Float32x)) var__Float32x __attribute__ ((unused)); > > | ^~~~~~~~~~~~~ > > > > Which gcc version are you using? I recall that we saw some issues on some > targets when _Float32x was added, but I didn't see any build failures on > master with recent gcc. I think we still might have some issues with > older gcc trying to build recent glibc, I fixed some issues on some targets > but I did check all of them. The version used still quoted above along with my reservation, but the whole point of my recent Alpha/Linux activity has been implementing a workaround in GCC for an architectural misfeature with non-BWX Alpha microarchitectures (that is EV4, EV45, EV5) so that support for this hardware is retained in the Linux kernel. Which means I'll be using GCC 15 master really soon now. In fact, I've already upgraded a few days ago, for GCC PR target/115526 I was requested to verify a fix for. I think it may make sense to address these compilation failures regardless, unless they were merely a transient misfeature of an unreleased snapshot of GCC. I'll rerun glibc regression testing with GCC 15 then, also to have glibc side results for the upcoming workaround, which may actually fix some issues, but that won't likely be before I have fixed the networking failure in my lab, because as I say the instability of the network driver and/or Ethernet interface may play factor here. There are driver warnings issued to the kernel log even in normal operation, so I suspect there is something fishy going on there and I may not be able to find time to investigate *yet another* issue, with the network driver this time. Also these locale OOM failures are a real pain, perhaps I'll be able to avoid them by lowering RLIMIT_DATA yet more. I long for a RAM upgrade for this box, but it takes time and effort to chase such stuff, so it won't be anytime soon. Conversely GCC verification runs very smoothly with my Alpha box and completes within short of a day across all the frontends and libraries. But that's no surprise, glibc verification has always been more demanding. Maciej
On Mon, 15 Jul 2024, Maciej W. Rozycki wrote: > > >>>> of which 90 failures in nptl/. There may be issues with the compiler as > > >>>> well (GCC 13.0.0 20221118). > [...] > > > There have been 45 compilation failures like this: > > > > > > .../math/test-tgmath3-atan2.c: In function 'test_atan2_84': > > > .../math/test-tgmath3-atan2.c:903:59: error: conflicting types for 'var__Float32x'; have 'double' > > > 903 | extern typeof (atan2 (vol_var__Float32x, vol_var_char)) var__Float32x__attribute__ ((unused)); > > > | ^~~~~~~~~~~~~ > > > .../math/test-tgmath3-atan2.c:855:64: note: previous declaration of 'var__Float32x' with type '_Float32x' > > > 855 | extern typeof (atan2 (vol_var__Float32x, vol_var__Float32x)) var__Float32x __attribute__ ((unused)); > > > | ^~~~~~~~~~~~~ > > > > > > > Which gcc version are you using? I recall that we saw some issues on some > > targets when _Float32x was added, but I didn't see any build failures on > > master with recent gcc. I think we still might have some issues with > > older gcc trying to build recent glibc, I fixed some issues on some targets > > but I did check all of them. > > The version used still quoted above along with my reservation, but the > whole point of my recent Alpha/Linux activity has been implementing a > workaround in GCC for an architectural misfeature with non-BWX Alpha > microarchitectures (that is EV4, EV45, EV5) so that support for this > hardware is retained in the Linux kernel. Which means I'll be using GCC > 15 master really soon now. Scratch it, I got the MIPS and the Alpha port confused here, sorry. I guess ETOOMANYCONTEXTS happened here. I won't upgrade the MIPS compiler beyond GCC 13, because soon afterwards a new port maintainer was appointed by the GCC Steering Committee despite my objection and shortly changes started being fast-tracked to the port without proper review, so I don't trust the MIPS compiler anymore. I can upgrade to the GCC 13 branch though and report back. Maciej
On 15/07/24 13:50, Maciej W. Rozycki wrote: > On Mon, 15 Jul 2024, Maciej W. Rozycki wrote: > >>>>>>> of which 90 failures in nptl/. There may be issues with the compiler as >>>>>>> well (GCC 13.0.0 20221118). >> [...] >>>> There have been 45 compilation failures like this: >>>> >>>> .../math/test-tgmath3-atan2.c: In function 'test_atan2_84': >>>> .../math/test-tgmath3-atan2.c:903:59: error: conflicting types for 'var__Float32x'; have 'double' >>>> 903 | extern typeof (atan2 (vol_var__Float32x, vol_var_char)) var__Float32x__attribute__ ((unused)); >>>> | ^~~~~~~~~~~~~ >>>> .../math/test-tgmath3-atan2.c:855:64: note: previous declaration of 'var__Float32x' with type '_Float32x' >>>> 855 | extern typeof (atan2 (vol_var__Float32x, vol_var__Float32x)) var__Float32x __attribute__ ((unused)); >>>> | ^~~~~~~~~~~~~ >>>> >>> >>> Which gcc version are you using? I recall that we saw some issues on some >>> targets when _Float32x was added, but I didn't see any build failures on >>> master with recent gcc. I think we still might have some issues with >>> older gcc trying to build recent glibc, I fixed some issues on some targets >>> but I did check all of them. >> >> The version used still quoted above along with my reservation, but the >> whole point of my recent Alpha/Linux activity has been implementing a >> workaround in GCC for an architectural misfeature with non-BWX Alpha >> microarchitectures (that is EV4, EV45, EV5) so that support for this >> hardware is retained in the Linux kernel. Which means I'll be using GCC >> 15 master really soon now. > > Scratch it, I got the MIPS and the Alpha port confused here, sorry. I > guess ETOOMANYCONTEXTS happened here. > > I won't upgrade the MIPS compiler beyond GCC 13, because soon afterwards > a new port maintainer was appointed by the GCC Steering Committee despite > my objection and shortly changes started being fast-tracked to the port > without proper review, so I don't trust the MIPS compiler anymore. I can > upgrade to the GCC 13 branch though and report back. Sorry, it was not clear which version you saw the _Float32x issue, was it with gcc 13 or with gcc 15? For gcc 13/14 I have multiple builds with recent glibc and I haven't see any issue on multiple MIPS ABIs, so it might something with master branch. I don't keep track as often as with gcc release branches.
On Mon, 15 Jul 2024, Adhemerval Zanella Netto wrote: > > I won't upgrade the MIPS compiler beyond GCC 13, because soon afterwards > > a new port maintainer was appointed by the GCC Steering Committee despite > > my objection and shortly changes started being fast-tracked to the port > > without proper review, so I don't trust the MIPS compiler anymore. I can > > upgrade to the GCC 13 branch though and report back. > > Sorry, it was not clear which version you saw the _Float32x issue, was it > with gcc 13 or with gcc 15? > > For gcc 13/14 I have multiple builds with recent glibc and I haven't see > any issue on multiple MIPS ABIs, so it might something with master branch. > I don't keep track as often as with gcc release branches. This was specifically GCC 13.0.0 20221118 as noted, i.e. around the start of Stage 3. Maciej
On Mon, 15 Jul 2024, Maciej W. Rozycki wrote: > On Mon, 15 Jul 2024, Adhemerval Zanella Netto wrote: > > > > I won't upgrade the MIPS compiler beyond GCC 13, because soon afterwards > > > a new port maintainer was appointed by the GCC Steering Committee despite > > > my objection and shortly changes started being fast-tracked to the port > > > without proper review, so I don't trust the MIPS compiler anymore. I can > > > upgrade to the GCC 13 branch though and report back. > > > > Sorry, it was not clear which version you saw the _Float32x issue, was it > > with gcc 13 or with gcc 15? > > > > For gcc 13/14 I have multiple builds with recent glibc and I haven't see > > any issue on multiple MIPS ABIs, so it might something with master branch. > > I don't keep track as often as with gcc release branches. > > This was specifically GCC 13.0.0 20221118 as noted, i.e. around the start > of Stage 3. You can't expect old prerelease versions of GCC to work with glibc headers in general. In this case, <tgmath.h> after glibc commit 8a78f833d670f86302f2d0c32eb1e4357d9166ff (C2x semantics for <tgmath.h>) assumes that GCC 13 means GCC commit 5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e (c: C2x semantics for __builtin_tgmath) or later (6 Jan 2023), and a mismatch means you should expect test failures such as you saw.
On Fri, 26 Jul 2024, Joseph Myers wrote: > > > Sorry, it was not clear which version you saw the _Float32x issue, was it > > > with gcc 13 or with gcc 15? > > > > > > For gcc 13/14 I have multiple builds with recent glibc and I haven't see > > > any issue on multiple MIPS ABIs, so it might something with master branch. > > > I don't keep track as often as with gcc release branches. > > > > This was specifically GCC 13.0.0 20221118 as noted, i.e. around the start > > of Stage 3. > > You can't expect old prerelease versions of GCC to work with glibc headers > in general. In this case, <tgmath.h> after glibc commit > 8a78f833d670f86302f2d0c32eb1e4357d9166ff (C2x semantics for <tgmath.h>) > assumes that GCC 13 means GCC commit > 5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e (c: C2x semantics for > __builtin_tgmath) or later (6 Jan 2023), and a mismatch means you should > expect test failures such as you saw. Good point, thanks. When working on one toolchain component I tend not to upgrade the other ones so as not to introduce variables into the picture. In this case I just picked whatever I had left from an earlier effort, as it was meant to check for any new regressions only and not the overall state at that point. As I noted upthread I'll upgrade to GCC 13.3 sometime, perhaps towards the end of this week even and rerun verification to see what the result look like. Maciej
On Mon, 29 Jul 2024, Maciej W. Rozycki wrote: > > You can't expect old prerelease versions of GCC to work with glibc headers > > in general. In this case, <tgmath.h> after glibc commit > > 8a78f833d670f86302f2d0c32eb1e4357d9166ff (C2x semantics for <tgmath.h>) > > assumes that GCC 13 means GCC commit > > 5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e (c: C2x semantics for > > __builtin_tgmath) or later (6 Jan 2023), and a mismatch means you should > > expect test failures such as you saw. > > Good point, thanks. When working on one toolchain component I tend not > to upgrade the other ones so as not to introduce variables into the > picture. In this case I just picked whatever I had left from an earlier > effort, as it was meant to check for any new regressions only and not the > overall state at that point. As I noted upthread I'll upgrade to GCC 13.3 > sometime, perhaps towards the end of this week even and rerun verification > to see what the result look like. I figured out I may not be able to trust MIPS/GCC versions beyond 13.2.0. Here is the summary of results for that GCC version then and current glibc master: === Summary of results === 149 FAIL 4354 PASS 84 UNSUPPORTED 23 XFAIL 2 XPASS All the build failures are gone. There have been test 104 execution timeouts, of which 76 in nptl/ (which do not go away with TIMEOUTFACTOR of up to 16, which seems to indicate these are actual test failures rather than consequences of a slow target, which it isn't anyway), 9 segmentation faults, 3 aborts, and 33 failures of a different kind. Maciej
Index: glibc/nptl/tst-sem11.c =================================================================== --- glibc.orig/nptl/tst-sem11.c +++ glibc/nptl/tst-sem11.c @@ -29,15 +29,15 @@ static void * tf (void *arg) { -#ifdef PREPARE - PREPARE +#ifdef TF_PREPARE + TF_PREPARE #endif SEM_WAIT (arg); return NULL; } int -main (void) +do_test (void) { int tries = 5; pthread_t th; @@ -101,3 +101,5 @@ main (void) return 0; } + +#include <support/test-driver.c> Index: glibc/nptl/tst-sem12.c =================================================================== --- glibc.orig/nptl/tst-sem12.c +++ glibc/nptl/tst-sem12.c @@ -20,7 +20,7 @@ #include <sys/time.h> -#define PREPARE \ +#define TF_PREPARE \ struct timespec ts; \ struct timeval tv; \ gettimeofday (&tv, NULL); \
From: Maciej W. Rozycki <macro@redhat.com> Fix an issue with commit 2af4e3e5668f ("Test of semaphores.") by making the tst-sem11 and tst-sem12 tests use the test driver, preventing them from ever causing testing to hang forever and never complete, such as currently happening with the 'mips-linux-gnu' (o32 ABI) target. Adjust the name of the PREPARE macro, which clashes with the interpretation of its presence by the test driver, by using a TF_ prefix in reference to the name of the 'tf' function. --- nptl/tst-sem11.c | 8 +++++--- nptl/tst-sem12.c | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-) glibc-tst-sem11-test-driver.diff