On Jul 11, 2025, Christophe Lyon <christophe.l...@linaro.org> wrote:
> I have another concern (hence cc'ing Alexandre): vect.exp calls
> check_vect_support_and_set_flags which defines dg-do-what-default
> according to what it discovers, meaning that for some targets these
> tests are 'run' and on others they are just 'compile'.
> So I suppose we should use 'dg-require-effective-target
> vect_early_break_hw' only when running the tests and
> 'dg-require-effective-target vect_early_break' when compiling them?
Yeah, we may have use for some new dg-require-effective-target variants,
say dg-require-effective-target-for-link or
dg-require-effective-target-for-run to account for this sort of
conditional requirement.
That said, testsuite maintainers have been, erhm, less than responsive
lately, and I've had a number of patches, including a fix for a bug I
introduced that others have also attempted to fix, that have been
unreviewed for 3 months today.
A significant part of my work has required significant attention to the
GCC testsuite; I wonder if it would make sense for me to volunteer to be
appointed as testsuite co-maintainer, or reviewer, or somesuch. Should
I take any steps towards that end, is this enough of a hint, hint ;-),
or is the fact that this hasn't happened for so long a hint that *I*
should take that it's unwanted for some reason? ;-)
> I suppose at the moment we completely skip these tests, while would
> could at least compile them on some targets?
*nod*. I'm not sure how much sense it makes to compile these specific
tests when the feature is not available, but it shouldn't hurt. Perhaps
instead of xfail we should change the dg-final scans to have target
requirements instead, that would be ignored if the feature is not
present.
Now, as for the problem at hand, IIUC there's a disconnect between the
vector support that check_vect_support_and_set_flags tests for, and the
vector support that these tests check for. The compile/run default set
by the former doesn't necessarily apply to the latter; ISTM that, for
tests with stricter vector unit requirements, we *should* IMHO consider
overriding the action in these tests with dg-do-if (*):
/* { dg-do-if compile { target vect_early_break } } */
/* { dg-do-if run { target vect_early_break_hw } } */
and drop the corresponding dg-require-effective-target directives.
I also wonder whether it would make sense for
check_vect_support_and_set_flags to try arm_v8_neon _ok and _hw, and go
for that for the default options and actions.
(*) provided that either of the identical patches that fix it get in
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684734.html
--
Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
