> On 15 Sep 2025, at 10:00, Jiang, Haochen <haochen.ji...@intel.com> wrote:
>
>> From: Jiang, Haochen
>> Sent: Monday, September 15, 2025 11:34 AM
>>
>>> From: Jiang, Haochen
>>> Sent: Monday, September 15, 2025 11:17 AM
>>>
>>>> From: Richard Earnshaw (lists) <richard.earns...@arm.com>
>>>> Sent: Thursday, September 11, 2025 1:24 AM
>>>>
>>>> On 10/09/2025 14:06, Jeff Law wrote:
>>>>>
>>>>>
>>>>> On 9/10/25 4:23 AM, Iain Sandoe wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> are there any plans to deal with this new reported data?
>>>>>> if not, I’d welcome a switch on the script - so that one could at least
>>>>>> elect
>>>>>> only to report new dups ..
>>>>> Yea. I need to go through my results as well, it was a bit overwhelming.
>>>>>
>>>>> Given the filename, opt flags and scan string are in the testname, it's a
>>>>> bit
>>>> surprising to hear that the dg-finals are triggering :(
>>>>>
>>>>> jeff
>>>>
>>>> With Christophe's patch from earlier today I see ~100 dup tests in gcc.sum
>>> for
>>>> arm (for two variants, so probably about 50). But even that is an
>>>
>>> For x86 make check, the sums reported me 1674 under Non-unique tests
>>> section in total (9 sums).
>>>
>>> I believe it is a good change to not fool the script, but could we add an
>>> option
>>> to bypass that? It is exploding compare tests for users (at least for me
>>> testing
>>> the patch) before most of them fixed and it needs time for all the
>> components
>>> to do that. 1600+ non-unique at the top of the report makes users hard to
>>> find the thing they want for now.
>>>
>>> I have attached the log I got for x86 unix for that section as a ref.
>>>
>>
>> Forgot to mention, I appreciate the script to show the issue under i386
>> testsuite and I am fixing them one by one. It did reflect bugs.
>>
>> Maybe we need a Bugzilla to fix all the issues in GCC16 for the log
>> I attached for x86 (and other backends)?
>>
>
> I did a fix for i386 target tests, after the patch got committed, at least
> for x86 backend only tests, they should be ok. The whole x86 backend
> only tests are quite simple.
>
> For other tests, take the test g++.dg/lto/odr-1 as example, the
> problem is caused by there are six different options to be tested, and
> they all output:
>
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_0.C line 3)
> PASS: g++.dg/lto/odr-1 at line 4 (test for LTO warnings, odr-1_0.C line 3)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_0.C line 5)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_0.C line 6)
> PASS: g++.dg/lto/odr-1 at line 7 (test for LTO warnings, odr-1_0.C line 6)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_1.C line 2)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_1.C line 4)
> PASS: g++.dg/lto/odr-1 at line 5 (test for LTO warnings, odr-1_1.C line 4)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_1.C line 6)
> PASS: g++.dg/lto/odr-1 (test for LTO warnings, odr-1_1.C line 7)
>
> This is where causing the non-unique issue.
>
> However, I do see something like this in test log where it append
> options, probably generated by dejagnu's dg-test when we passed
> the files and options:
>
> PASS: g++.dg/lto/odr-1 cp_lto_odr-1_0.o-cp_lto_odr-1_1.o link, -O0 -flto
> -flto-partition=1to1 -fno-use-linker-plugin
>
> That means we need to do similar things for those tests just like dejagnu,
> i.e., add test options into test output line, not only for the initial
> link/compiler/assemble/run, where I guess dajagnu did for us, but also for
> those extra tests in file.
Most (maybe all) of the disambiguation using iterated test options is done in
the GCC cusomisation of DejaGNU (so it’s under our local control).
There are places ( like dg-final and perhaps some of the lto checks ) that do
not have a slot to add that information - so someone needs to update the
dg-xxxx processes (or figure out how to add the extra information at the next
level up).
Iain
