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

[Jeff Law <jeffreyalaw@gmail.com>]

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?  These tests work on the other linux targets AFAIK.

jeff