[ping^2] [PATCH] testsuite: Add multiple scan introducers to check-function-bodies.

Hi folks,

> On 13 Jul 2026, at 14:48, Iain Sandoe <[email protected]> wrote:
>=20
> Hi folks,
>=20
>=20
>> On 23 Jun 2026, at 16:44, Iain Sandoe <[email protected]> wrote:
>>=20
>> Hi Folks...
>>=20
>>> On 16 Jun 2026, at 09:59, Iain Sandoe <[email protected]> wrote:
>>>=20
>>> Hi Rainer,
>>>=20
>>>> On 16 Jun 2026, at 09:10, Rainer Orth <[email protected]> =
wrote:
>>>=20
>>>>> Tested on aarch64-darwin (and testing now on aarch64-linux),
>>>>> OK for trunk (assuming the Linux tests pass)?
>>>>=20
>>>> as I've said before, I very much like the syntax, but ...
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Viz:
>>>>> // { dg-final { check-function-bodies {"**" "*E"} "*/" "" { target =
{ ! *-*-darwin* } } {\.L[0-9]+} } }
>>>>> // { dg-final { check-function-bodies {"**" "*M"} "*/" "" { target =
*-*-darwin* } {\.L[0-9]+} } }
>>>>=20
>>>> ... 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.
>>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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=E2=80=99d =
done that so far with
>>> a different terminator for each case .. but perhaps it would work =
just retaining
>>> =E2=80=98*/=E2=80=98 at the expense of a little less readability of =
the match blocks.
>>>=20
>>> that said, none ot those are show-stoppers for me =E2=80=A6
>>>=20
>>>> I also think that this is doable without too much churn:
>>>>=20
>>>> * Move the functionality into check-function-bodies, always =
applying it.
>>>>=20
>>>> * 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.
>>>=20
>>> well, I=E2=80=99d guess that just means adding =E2=80=9C** =E2=80=9C =
to the config content for avr.
>>>=20
>>>> * 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.
>>>>=20
>>>> I think this would be a large win for everyone with manageable
>>>> complexity.
>>>=20
>>> Sure, I don=E2=80=99t think that the change to the patch is a big =
deal - it=E2=80=99s 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).
>>=20
>> 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.
>>=20
>> (it would allow per-target customisation too - although I=E2=80=99ve =
currently not needed
>> to do that)
>>=20
>> =E2=80=94=20
>> 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.
>>=20
>> Hopefully, the aarch64 tests will be more profitable, since they tend =
to be more
>> refined.
>>=20
>> The other thing that would be nice to sort out is that there=E2=80=99s =
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.
>>=20
>> Aarch64 conversely hardly ever does this - and so arg 5 is almost =
always empty.
>>=20
>> (However, I don=E2=80=99t plan on working on that at present)
>>=20
>> Thoughts?
>> should we go with this for trunk?
>> Iain
>>=20
>> <0001-testsuite-Add-multiple-scan-introducers-to-check-fun.patch>
>>=20
>=20