On Tue, 29 Oct 2024 at 19:25, Sam James sam@gentoo.org wrote:

Christophe Lyon christophe.lyon@linaro.org writes:

...

On Sat, 26 Oct 2024 at 14:17, Sam James via Gcc-regression gcc-regression@gcc.gnu.org wrote:

...

ci_notify@linaro.org writes:

...

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 understand 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-1388 , please let us know if you are looking at the problem and/or when you have a fix.

Should be fixed with r15-4692-g40fedaf35fa99a9728d5b84d47035f4c92e1ba90.

Thanks for the feedback. So now it's an "assemble" only test, rather than a "(LTO) link" one?

Yes. What I'm doing (and have been doing the last few months) is finding tests which were never being run and fixing them up. In this case, I found a bunch of tests in lto/ which were being ignored because their filename was wrong. I missed that the tbaa test was broken when comparing results at first after I'd renamed it and made some initial fixes.

In the end, there were a few problems left:

• when doing a "proper LTO" test, the needed dump isn't available (so

moved to be an assemble + LTO test);

• the scan fails when the dump needed is actually possible, so I XFAIL'd

and filed a bug for Honza to look at (PR117299).

Great, thanks for the clarification.

Christophe

thanks, sam