On Mon, 1 Sept 2025 at 11:37, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > On 29/08/2025 14:48, Christophe Lyon wrote: > > On Fri, 29 Aug 2025 at 11:35, Richard Earnshaw via Gcc <gcc@gcc.gnu.org> > > wrote: > >> > >> On 29/08/2025 04:08, Jacob Bachmeyer wrote: > >>> On 8/28/25 10:10, Jeff Law wrote: > >>>> On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote: > >>>>> On 28/08/2025 15:01, Iain Sandoe wrote: > >>>>>> [...] > >>>>> > >>>>> Well really, the compare-tests script should report duplicate results > >>>>> as a problem as well, since > >>>>> > >>>>> PASS: abcd > >>>>> ... > >>>>> PASS: abcd > >>>>> > >>>>> is just a dup pass/fail waiting to happen. > >>>> Yup. A duplicate testname should be reported. These cause major > >>>> headaches if one passes, but the other fails -- it looks like a > >>>> regression to the comparison scripting we have. > >>> > >>> The problem with detecting duplicate names in the DejaGnu framework is > >>> that it would add memory overhead that scales with the number of tests > >>> and DejaGnu tries to avoid that kind of unbounded space requirement. > >>> (OK, it *is* bounded for any finite testsuite, but the idea of a > >>> steadily growing memory footprint during a test run still bothers me.) > >>> > >>> I suggest that the comparison script GCC uses is probably the best place > >>> to check for duplicate test names, since that seems to also be the > >>> script that can be confused by them. > >>> > >> > >> That's exactly what I was suggesting. Trying to do it in dejagnu would > >> be a nightmare given that we run multiple instances of it to get > >> parallel testing. > >> > > > > Which script do people use these days? Here is a quick patch for > > compare_tests, which actually detected duplicates ;-) > > > > I can commit that, if it helps. > > > > Thanks, > > > > Christophe > > > >> R. > >> > >>> > >>> -- Jacob > >>> > >>> > >> > > > +uniq -c "$before_s" | grep -v '^ 1 ' > "$before_u" > > uniq -dc "$before_s" > > will do that without needing the grep step and thus depending on the exact > formatting of the count field; or you could drop the -c if you don't actually > want the count for some other reason. >
Thanks for the suggestion, I'll post a proper patch with an updated version. I added the removal of empty lines before counting the duplicates. Thanks, Christophe > R.
