On Wed, 10 Sept 2025 at 15:41, Iain Sandoe <idsan...@googlemail.com> wrote: > > > > > On 10 Sep 2025, at 13:42, Christophe Lyon <christophe.l...@linaro.org> > > wrote: > > > > On Wed, 10 Sept 2025 at 12:23, Iain Sandoe <idsan...@googlemail.com> wrote: > >> > >> > >> > >>> On 10 Sep 2025, at 11:12, Richard Earnshaw (lists) > >>> <richard.earns...@arm.com> wrote: > >>> > >>> On 10/09/2025 10:54, Christophe Lyon wrote: > >>>> If the results include several configurations (schedule of > >>>> variations), do not report summary lines as duplicates. Indeed with > >>>> several configurations, it's likely that the results contain the same > >>>> > >>>> # of expected passes XXXXX > >>>> > >>>> The patch just keeps lines starting with test state prefix to avoid > >>>> this problem. > >>>> > >>>> contrib/ChangeLog: > >>>> > >>>> * compare_tests: Improve non-unique tests report when testing > >>>> several configurations. > >>> > >>> OK. > >> > >> Now we have this facility - and it is firing on my testboxes (since i use > >> this > >> script to post-process [per .sum file for stability]) - I looked through a > >> few of > >> the reported cases and they seem genuiene - but particularly in respect of > >> dg-final ones, hard to see how they can be disambiguated without we make > >> dg-final able to add some tag to differentiate. > > > > I must confess I didn't look at the list in detail, hoping that people > > would gradually / promptly fix things of interest to then ;-) > > > >> > >> are there any plans to deal with this new reported data? > > No plan on my side at least, I just wrote this patch and the previous > > after discussing (on- and off-list), and that seemed very quick to do > > ;-) > > > >> if not, I’d welcome a switch on the script - so that one could at least > >> elect > >> only to report new dups .. > > new dups as in "new dups compared to the list of dups of them previous run" > > ? > > I think that there’s merit to always looking at changes for the worse (I > suppose > these cannot be called exactly ‘regressions’) - so new dups since the last > run, > yes. > > The list of all dups is very useful to someone who plans to work through them > (or even the ones they feel responsible for) - but I’d say it’s value as a > constant reminder is much less …
I naively thought all of them would be fixed in a couple of days after my previous patch ;-) > > > or just disable this new facility (and come back to the behaviour > > before my previous patch? > > No, IMO, this is a great addition .. I think we need to fix these issues - > dup tests > make the sorting process much more fragile. > > cheera > Iain > > > > > Thanks, > > > > Christophe > > > >> > >> thanks > >> Iain >
