Hi folks,
> On 23 Jun 2026, at 16:44, Iain Sandoe <[email protected]> wrote: > > 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> >
