Re: [PATCH 2/3] Enabled LRA for ia64.

[Jonathan Wakely <jwakely@redhat.com>]

On Thu, 13 Jun 2024 at 15:16, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 13 Jun 2024 at 15:11, Jeff Law <jeffreyalaw@gmail.com> wrote:
> >
> >
> >
> > On 6/13/24 4:33 AM, Jonathan Wakely wrote:
> > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@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.