Hi Folks... > On 16 Jun 2026, at 09:59, Iain Sandoe <[email protected]> wrote: > > Hi Rainer, > >> On 16 Jun 2026, at 09:10, Rainer Orth <[email protected]> wrote: > >>> Tested on aarch64-darwin (and testing now on aarch64-linux), >>> OK for trunk (assuming the Linux tests pass)? >> >> as I've said before, I very much like the syntax, but ... >> >>> The motivation for this is that it is not unusal for subtargets to have >>> substantially equivalent code-gen but differing in details. This provision >>> avoid duplication of the common sections. >>> >>> Viz: >>> // { dg-final { check-function-bodies {"**" "*E"} "*/" "" { target { ! >>> *-*-darwin* } } {\.L[0-9]+} } } >>> // { dg-final { check-function-bodies {"**" "*M"} "*/" "" { target >>> *-*-darwin* } {\.L[0-9]+} } } >> >> ... this is going the wrong direction IMO: this will be duplicated into >> every test that needs different prefixes. The testsuite is already >> riddled with such duplication, and I'd rather see it reduced than >> increase it. >> >>> This says that body scan lines can begin with either ** or *E for ELF >>> targets >>> (or pecoff, I guess) >>> but that Darwin targets should scan for either ** or *M. >> >> Imagine (which I think is plausible) that PE-COFF support is really >> added: this would make the default (ELF) case ever harder to read, apart >> from having to modify this section in every single test involved. >> >> If the multiple prefix support were moved into check-function-bodies >> instead, all this would simply vanish, improving both readability and >> maintainablity. Witness Richard's change to patch to move the explicit >> dg-add-options check_function_bodies into dg-final. > > I agree with all of this, in principle; > my residual objections are: > - it means that the process of adding a change to deal with a new test > granularity now means editing a file in testsuite/lib instead of making a > change local to one specific test. > - it hides the meaning of the prefixes away outside the actual test (meaning > that one has to look in two places to understand the intent). > - We will probably still have cases where the code-gen is so dissimilar > between > targets that multiple match blocks would be needed. I’d done that so far > with > a different terminator for each case .. but perhaps it would work just > retaining > ‘*/‘ at the expense of a little less readability of the match blocks. > > that said, none ot those are show-stoppers for me … > >> I also think that this is doable without too much churn: >> >> * Move the functionality into check-function-bodies, always applying it. >> >> * Given that only some of the AVR tests (28 total) use a prefix other >> than "**" ("** ") for some unknown reason, change those tests to also >> use "**" like everyone else. > > well, I’d guess that just means adding “** “ to the config content for avr. > >> * Then, in check-function-bodies the explicit PREFIX arg can simply be >> ignored (or rather checked that that it's "**" as in all tests so >> far) and replaced by the magic above. >> >> I think this would be a large win for everyone with manageable >> complexity. > > Sure, I don’t think that the change to the patch is a big deal - it’s just a > question of how we want it to look to the end-user (who is perhaps not > so quick to want to edit the core testsuite code).
Here is a version that has two modes (which does what you want but allows
a fall-back when that does not work out):
1. auto - it applies a pre-determined set of introducers without requiring
intervention.
2. It retains the ability for a user to override this with a specific set.
(it would allow per-target customisation too - although I’ve currently not
needed
to do that)
—
In the X86 tests, this helps one test - most of the ones that needed handling
were because the PIC / non-PIC codegen is too different and needs separate
match blocks.
Hopefully, the aarch64 tests will be more profitable, since they tend to be more
refined.
The other thing that would be nice to sort out is that there’s an idiomatic
difference
between X86 and aarch64 scans - where the x86 defaults to checking labels,
which means that argument 5 of the directive is always {^\t?\.} or so.
Aarch64 conversely hardly ever does this - and so arg 5 is almost always empty.
(However, I don’t plan on working on that at present)
Thoughts?
should we go with this for trunk?
Iain
0001-testsuite-Add-multiple-scan-introducers-to-check-fun.patch
Description: Binary data
