Re: [Linaro-TCWG-CI] gdb-14-branchpoint-1411-g033bc67bdb0: FAIL: 2 regressions on arm

2024-03-12 Thread Maxim Kuvyrkov
> On Mar 11, 2024, at 20:52, Jonathan Wakely  wrote:
> 
> On Mon, 11 Mar 2024 at 16:38, Maxim Kuvyrkov  
> wrote:
>> 
>>> On Jan 30, 2024, at 23:03, ci_not...@linaro.org wrote:
>>> 
>>> Dear contributor, our automatic CI has detected problems related to your 
>>> patch(es).  Please find some details below.  If you have any questions, 
>>> please follow up on linaro-toolchain@lists.linaro.org mailing list, 
>>> Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain 
>>> developer on the usual project channel.
>>> 
>>> We appreciate that it might be difficult to find the necessary logs or 
>>> reproduce the issue locally. If you can't get what you need from our CI 
>>> within minutes, let us know and we will be happy to help.
>>> 
>>> We track this report status in https://linaro.atlassian.net/browse/GNU-1136 
>>> , please let us know if you are looking at the problem and/or when you have 
>>> a fix.
>>> 
>>> In  master-arm after:
>>> 
>>> | commit gdb-14-branchpoint-1411-g033bc67bdb0
>>> | Author: Tom Tromey 
>>> | Date:   Tue Sep 19 17:39:31 2023 -0600
>>> |
>>> | Only search types in cp_lookup_rtti_type
>>> |
>>> | This changes cp_lookup_rtti_type to only search for types -- not
>>> | functions or variables.  Due to the symbol-matching hack, this could
>>> | just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also
>>> | I hold on to some hope that perhaps the hack can someday be removed.
>>> 
>>> FAIL: 2 regressions
>>> 
>>> regressions.sum:
>>> === libstdc++ tests ===
>>> 
>>> Running libstdc++:libstdc++-prettyprinters/prettyprinters.exp ...
>>> FAIL: libstdc++-prettyprinters/cxx11.cc print ecmiaow
>>> FAIL: libstdc++-prettyprinters/cxx11.cc print emiaow
>> 
>> Hi Tom,
>> Hi Jonathan,
>> 
>> After the above GDB patch I see 2 new failures both for aarch64-linux-gnu 
>> and arm-linux-gnueabihf in GCC's libstdc++ testsuite.  The log [1] says:
>> ===
>> $35 = warning: RTTI symbol not found for class 'main::custom_cat'
>> warning: RTTI symbol not found for class 'main::custom_cat'
>> got: $35 = warning: RTTI symbol not found for class 'main::custom_cat'
>> FAIL: libstdc++-prettyprinters/cxx11.cc print emiaow
>> skipping: warning: RTTI symbol not found for class 'main::custom_cat'
>> std::error_code = {std::_V2::error_category: 42}
>> skipping: std::error_code = {std::_V2::error_category: 42}
>> $36 = warning: RTTI symbol not found for class 'main::custom_cat'
>> warning: RTTI symbol not found for class 'main::custom_cat'
>> got: $36 = warning: RTTI symbol not found for class 'main::custom_cat'
>> FAIL: libstdc++-prettyprinters/cxx11.cc print ecmiaow
>> ===
>> 
>> Which way should I dig -- GDB or libstdc++?  Does this look like libstdc++ 
>> testcase needs an update?
> 
> 
> Just a guess, but maybe making the type global instead of a local type
> (with no linkage) will solve it:
> 
> --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
> +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
> @@ -63,6 +63,11 @@ struct datum
> 
> std::unique_ptr global;
> 
> +struct custom_cat : std::error_category {
> +  const char* name() const noexcept { return "miaow"; }
> +  std::string message(int) const { return ""; }
> +};
> +
> int
> main()
> {
> @@ -179,10 +184,7 @@ main()
>  std::error_condition ecinval =
> std::make_error_condition(std::errc::invalid_argument);
>  // { dg-final { note-test ecinval {std::error_condition =
> {"generic": EINVAL}} } }
> 
> -  struct custom_cat : std::error_category {
> -const char* name() const noexcept { return "miaow"; }
> -std::string message(int) const { return ""; }
> -  } cat;
> +  custom_cat cat;
>  std::error_code emiaow(42, cat);
>  // { dg-final { note-test emiaow {std::error_code = {custom_cat: 42}} } }
>  std::error_condition ecmiaow(42, cat);
> 
> 
> If this works, I think this change to the test is reasonable. A local
> type as an error_category probably doesn't make sense in real code.
> 
> But I don't know if this is revealing some issue with Tom's patch and
> how it handles local types (or any types without linkage).

Hi Jonathan,

Your above change to cxx11.cc  fixes the failures [1].  Would 
you please commit it?

Thanks!

[1] 
https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-precommit/1/artifact/artifacts/artifacts.precommit/notify/mail-body.txt/*view*/


--
Maxim Kuvyrkov
https://www.linaro.org


___
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org


Re: [Linaro-TCWG-CI] gdb-14-branchpoint-1356-g7737b133640: FAIL: 1 regressions on arm

2024-03-12 Thread Tom Tromey
> Maxim Kuvyrkov  writes:

>> | commit gdb-14-branchpoint-1356-g7737b133640
>> | Author: Tom Tromey 
>> | Date:   Tue Jan 9 11:47:17 2024 -0700
>> | 
>> | Handle DW_AT_endianity on enumeration types
>> | 
>> | A user found that gdb would not correctly print a field from an Ada
>> | record using the scalar storage order feature.  We tracked this down
>> | to a combination of problems.
>> | 
>> | First, GCC did not emit DW_AT_endianity on the enumeration type.
>> | ... 14 lines of the commit log omitted.

> I see the above failure for both aarch64-linux-gnu and
> arm-linux-gnueabihf in our testing.  The log shows ([1]):

> (gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
> get_compiler_info: gcc-14-0-1

> Any idea what can be causing this?

> This failure happens in CI configurations where we track tip-of-trunk GCC.

This failure is what I would expect if your compiler does not have the
fix.  Can you see if your gcc includes this change?

commit 5d8b60effc7268448a94fbbbad923ab6871252cd
Author: Eric Botcazou 
Date:   Wed Jan 10 13:23:46 2024 +0100

Fix debug info for enumeration types with reverse Scalar_Storage_Order

This implements the support of DW_AT_endianity for enumeration types because
they are scalar and therefore, reverse Scalar_Storage_Order is supported for
them, but only when the -gstrict-dwarf switch is not passed because this is
an extension.

There is an associated GDB patch to be submitted to grok the new DWARF.

thanks,
Tom
___
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org


Re: [Linaro-TCWG-CI] gdb-14-branchpoint-1356-g7737b133640: FAIL: 1 regressions on arm

2024-03-12 Thread Maxim Kuvyrkov
> On Mar 12, 2024, at 00:14, Tom Tromey  wrote:
> 
>> Maxim Kuvyrkov  writes:
> 
>>> | commit gdb-14-branchpoint-1356-g7737b133640
>>> | Author: Tom Tromey 
>>> | Date:   Tue Jan 9 11:47:17 2024 -0700
>>> | 
>>> | Handle DW_AT_endianity on enumeration types
>>> | 
>>> | A user found that gdb would not correctly print a field from an Ada
>>> | record using the scalar storage order feature.  We tracked this down
>>> | to a combination of problems.
>>> | 
>>> | First, GCC did not emit DW_AT_endianity on the enumeration type.
>>> | ... 14 lines of the commit log omitted.
> 
>> I see the above failure for both aarch64-linux-gnu and
>> arm-linux-gnueabihf in our testing.  The log shows ([1]):
> 
>> (gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
>> get_compiler_info: gcc-14-0-1
> 
>> Any idea what can be causing this?
> 
>> This failure happens in CI configurations where we track tip-of-trunk GCC.
> 
> This failure is what I would expect if your compiler does not have the
> fix.  Can you see if your gcc includes this change?
> 
> commit 5d8b60effc7268448a94fbbbad923ab6871252cd
> Author: Eric Botcazou 
> Date:   Wed Jan 10 13:23:46 2024 +0100
> 
>Fix debug info for enumeration types with reverse Scalar_Storage_Order

Ah, now I understand.  While we do have the above commit in our GCC sources (we 
build tip-of-trunk in this CI configuration), we don't enable ada language.  So 
testsuite harness detects GCC version as 14.0 and enables the test, but actual 
gnat compiler is used from the distro package, which is much older.

We will consider enabling ada language in our CI builds, which should fix this.

Thanks for helping troubleshooting this!

--
Maxim Kuvyrkov
https://www.linaro.org


___
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org