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.