On Thu, 13 Jun 2024 at 15:16, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Thu, 13 Jun 2024 at 15:11, Jeff Law <jeffreya...@gmail.com> wrote: > > > > > > > > On 6/13/24 4:33 AM, Jonathan Wakely wrote: > > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.schei...@web.de> > > > wrote: > > >> > > >> Hi Jonathan, Richard, > > >> > > >> On 12.06.24 20:54, Jonathan Wakely wrote: > > >>> On 12/06/24 16:09 +0200, Frank Scheiner wrote: > > >>>> Dear Richard, > > >>>> > > >>>> On 12.06.24 13:01, Richard Biener wrote: > > >>>>> [...] > > >>>>> I can find two gcc-testresult postings, one appearantly with LRA > > >>>>> and one without? Both from May: > > >>>>> > > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > > >>>>> > > >>>>> somehow for example libstdc++ summaries were not merged, it might > > >>>>> be you do not have recent python installed on the system? Or you > > >>>>> didn't use contrib/test_summary to create those mails. > > >>>> > > >>>> No, I did not use contrib/test_summary. But I still have tarballs of > > >>>> both testsuite runs, so could still produce these summaries - I hope? > > >>> > > >>> It looks like the results at > > >>> https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are > > >>> just what's printed on standard out, including output from 'make -j4' > > >>> so not combined into one set of results. > > >> > > >> That's what it is, yes. > > >> > > >>> It would certainly be better to either get the results from the .sum > > >>> files, or just use the contrib/test_summary script to do that for you. > > >> > > >> Ok, I posted the results as created by contrib/test_summary now: > > >> > > >> 1. non-LRA version on [1] > > >> > > >> 2. LRA version on [2] > > >> > > >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html > > >> > > >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > > > > > Thanks! > > > > > > These ones are probably due to non-reserved names in glibc or kernel > > > headers: > > > > > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > > > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > > > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > > > > > The errors for all three are probably the same and should be > > > decipherable from libstdc++.log which will show which names defined as > > > macros in names.cc are clashing with names in system headers. > > And wouldn't failure of these imply that the headers are either ancient > > with some kind of pollution or that there's a ia64 specific goof in the > > headers? > > Yes, indeed. It probably means some ia64-specific structures in kernel > headers use non-reserved names like "next" or "ptr" or something, > instead of __next or __ptr. > > > These tests work on the other linux targets AFAIK. > > Most of them, yes. I think Jakub noticed some failures on s390x linux > recently, due to bad names in s390x-specific structs in the kernel > headers.
Ah yes, see r14-10076-gcf5f7791056b3e for details - the commit message has lots of info. There were problems in kernel headers and in s390x-specific parts of glibc.
