> On 15 Oct 2026, at 20:30, Iain Sandoe <[email protected]> wrote: > > .. gentle ping ... > >> On 4 Aug 2026, at 09:13, Iain Sandoe <[email protected]> wrote: >> >> Hi folks, >> >>> On 13 Jul 2026, at 14:48, Iain Sandoe <[email protected]> wrote: >>> >>> 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> >>>> >>> >> >
