Hi Richard,
> On Wed, 7 Jan 2026, Rainer Orth wrote:
>
>> Hi Richard,
>>
>> > On Wed, 7 Jan 2026, Rainer Orth wrote:
>> >
>> >> Hi Xi,
>> >>
>> >> > On Tue, 2026-01-06 at 09:54 +0100, Rainer Orth wrote:
>> >> >> The gcc.dg/tree-ssa/forwprop-43.c test currently FAILs on 32 and 64-bit
>> >> >> SPARC:
>> >> >>
>> >> >> FAIL: gcc.dg/tree-ssa/forwprop-43.c scan-tree-dump-times forwprop1
>> >> >> "VEC_PERM_EXPR" 10
>> >> >>
>> >> >> The dump has no reference to VEC_PERM_EXPR, so the scan needs to
>> >> >> guarded
>> >> >> by vect_perm.
>> >> >
>> >> > It will need to be moved to vect/ directory then. See
>> >> > https://gcc.gnu.org/PR113418.
>> >>
>> >> unfortunately this is not enough: when doing so the test wasn't run at
>> >> all. This happens because vect.exp only selects part of the files in
>> >> gcc.dg/vect based on patterns. Apart from forwprop-43.c, four more fall
>> >> through the cracks:
>> >>
>> >> gcc.dg/vect/gimplefe-40.c
>> >> gcc.dg/vect/gimplefe-41.c
>> >> gcc.dg/vect/group-no-gaps-1.c
>> >> gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c
>> >>
>> >> I wonder how best to address this: one could rename them to match one of
>> >> the existing patterns, probably just vect-*.c. However, future files
>> >> could well be missed again.
>> >>
>> >> Comments?
>> >
>> > I had started to transition the various pattern dependent extra
>> > options to dg-addtional-options but didn't manage to finish. So
>> > that's the solution, and then simply glob all *.c files.
>>
>> that's certainly the cleanest solution. Though largely mechanical, I'm
>> not sure we want to do this before the GCC 16 release, though.
>
> IMO it's perfect stage4 work.
fine with me :-) It would certainly avoid lots of confusion like this
one, and make vect.exp way more maintainable.
>> > But IMO some effective targets should maybe made to work outside
>> > of vect.exp? I think not all really require it, only some, and it's
>> > not well documented which?
>>
>> That would most certainly be welcome.
>>
>> Besides, there's quite a number of effective-target keywords not even
>> documented in sourcebuild.texi. I mean to add those that have
>> documentation in target-support.exp, create a PR for the rest to prompt
>> the authors to fix it, and add a test like gcc.src/maintainers.exp to
>> ensure things remain that way. No idea when I'll get to that, though.
>
> Yeah. Possibly also get an idea on the number of uses of the various
> effective targets - I'd expect a majority to be only used very few
> times, thus easy candidates for renaming.
Good idea: I'll add that to my list.
> The issue with outside-of-vect.exp usage is the use of
> check_cached_effective_target[_indexed]? I do wonder why we include
> target-supports.exp from testsuites where it isn't supported? It's
> name also does not suggest it's not suitable in general :/
Right. Besides, there are several additional ones throughout
g??.target/.../*.exp that might be more generally applicable.
There's certainly lots of potential for cleanup, as always when you
start looking at something.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
