[Bug testsuite/113418] New: Use of vect_* targetsin tests out of vect directories

[Bug testsuite/113418] New: Use of vect_* targetsin tests out of vect directories

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

            Bug ID: 113418
           Summary: Use of vect_* targetsin tests out of vect directories
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
[Phew, why do we allow empty reports? Just mishit "enter" and then this.]

The vect_* target selectors are evaluated with the options in
DEFAULT_VECTCFLAGS in effect, but these options are not automatically passed to
tests out of the vect directories.  This causes test failures to show up here
and there.

To me using vect_* target selectors out of vect directories is simply wrong. 
Instead of forcing the maintainers to fix these failures one by one, target by
target, we should just move the tests into vect directories, or adjust them not
to rely on vect_* target selectors.  And we should make a policy to disallow
using { target vect_* } in tests out of vect directories.

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-01-17

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. I ran into this 4 years ago and I fixed some.
My original attempt of fixing this,  ran into this on MIPS even:
https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538822.html

See https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538956.html for the
move suggestion.

Patch which moved the testcases that was found at the time:
https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538958.html

> we should just move the tests into vect directories
Yes like I did 4 years ago :).

Do you have a list of the ones that still use `{ target vect_*`; I think they
are all have been added in the last 4 years even since I did an audit back then
too?

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
In gcc.dg:

align-2.c
analyzer/torture/pr93350.c
analyzer/torture/uninit-bit-field-ref.c
bic-bitmask-13.c
bic-bitmask-14.c
bic-bitmask-15.c
bic-bitmask-16.c
bic-bitmask-17.c
bic-bitmask-18.c
bic-bitmask-19.c
bic-bitmask-20.c
bic-bitmask-21.c
bic-bitmask-22.c
bic-bitmask-7.c
gomp/_Atomic-4.c
gomp/pr87887-1.c
gomp/pr87887-2.c
gomp/pr88107.c
gomp/pr95108.c
graphite/run-id-5.c
graphite/run-id-6.c
graphite/vect-pr43423.c
lto/simd-function_0.c
pr104992.c
signbit-2.c
tree-ssa/gen-vect-11a.c
tree-ssa/gen-vect-11b.c
tree-ssa/gen-vect-11.c
tree-ssa/gen-vect-11c.c
tree-ssa/gen-vect-25.c
tree-ssa/gen-vect-26.c
tree-ssa/gen-vect-28.c
tree-ssa/gen-vect-2.c
tree-ssa/gen-vect-32.c
tree-ssa/gen-vect-34.c
tree-ssa/scev-16.c

In c-c++-common:

gomp/declare-variant-13.c
gomp/declare-variant-14.c
gomp/pr60823-2.c
gomp/pr60823-4.c

In gfortran.dg:

gomp/declare-variant-13.f90
gomp/declare-variant-14.f90
graphite/vect-pr40979.f90

I just found them with a simple grep command so there might be false positives
or false negatives.  There are also a dozen matches in gcc.target but I
consider them fine as the target maintainers should know exactly what they are
doing.

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linkw at gcc dot gnu.org

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for filing this, I just realized that it's unexpected to use vect_*
effective target checks outside */vect/ in generic test suites.

> 
> I just found them with a simple grep command so there might be false
> positives or false negatives.  There are also a dozen matches in gcc.target
> but I consider them fine as the target maintainers should know exactly what
> they are doing.

Yes, I think those in target should be fine, although they can be replaced with
some corresponding target specific check(s), sometimes the vect_* is more
readable.

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
For pr104992.c:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643697.html

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113418

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:889fbc9454e2d4e2b9a11a9e02b3b7e698edcd1c

commit r14-9290-g889fbc9454e2d4e2b9a11a9e02b3b7e698edcd1c
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Tue Jan 23 19:58:21 2024 +0800

    testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

    The vect_int_mod target selector is evaluated with the options in
    DEFAULT_VECTCFLAGS in effect, but these options are not automatically
    passed to tests out of the vect directories.  So this test fails on
    targets where integer vector modulo operation is supported but requiring
    an option to enable, for example LoongArch.

    In this test case, the only expected optimization not happened in
    original is in corge because it needs forward propogation.  So we can
    scan the forwprop2 dump (where the vector operation is not expanded to
    scalars yet) instead of optimized, then we don't need to consider
    vect_int_mod or not.

    gcc/testsuite/ChangeLog:

            PR testsuite/113418
            * gcc.dg/pr104992.c (dg-options): Use -fdump-tree-forwprop2
            instead of -fdump-tree-optimized.
            (dg-final): Scan forwprop2 dump instead of optimized, and remove
            the use of vect_int_mod.
            * lib/target-supports.exp (check_effective_target_vect_int_mod):
            Remove because it's not used anymore.