[2/2] nptl: Convert tst-sem11 and tst-sem12 tests to use the test driver

  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
  

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