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>
>>
>
