[Bug testsuite/106516] New: New test case gcc.dg/pr104992.c fails

[Bug testsuite/106516] New: New test case gcc.dg/pr104992.c fails

[seurer at gcc dot gnu.org]

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

            Bug ID: 106516
           Summary: New test case gcc.dg/pr104992.c fails
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:388fbbd895e72669909173c3003ae65c6483a3c2, r13-1916-g388fbbd895e726

I only saw this on a power 10 machine.

make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr104992.c"
FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9
# of expected passes            1
# of unexpected failures        1


commit 388fbbd895e72669909173c3003ae65c6483a3c2 (HEAD, refs/bisect/bad)
Author: Sam Feifer <sfeifer@redhat.com>
Date:   Fri Jul 29 09:44:48 2022 -0400

    match.pd: Add new division pattern [PR104992]


Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr104992.c   
-fdiagnostics-plain-output   -O2 -fdump-tree-optimized -S -o pr104992.s   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr104992.c
-fdiagnostics-plain-output -O2 -fdump-tree-optimized -S -o pr104992.s^M
PASS: gcc.dg/pr104992.c (test for excess errors)
gcc.dg/pr104992.c: pattern found 6 times
FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org
            Summary|New test case               |New test case
                   |gcc.dg/pr104992.c fails     |gcc.dg/pr104992.c fails on
                   |                            |power 10

--- Comment #1 from seurer at gcc dot gnu.org ---
I should have said it ONLY fails on power 10.  Works fine on power 9 and
earlier.

I can't find a valid email address for Sam Feifer to use for bugzilla.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |linkw at gcc dot gnu.org
   Last reconfirmed|                            |2022-08-04
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed, this is a test issue, power10 and up specific.

The difference comes from the function thud, it aims to test the pattern works
for vector type. Power10 starts to support the insn vmodsw for vector integer
mod.

So it gets:

  vector(4) int thud (vector(4) int x, vector(4) int y)

    _1 = x_3(D) % y_4(D);
    _2 = _1 == { 0, 0, 0, 0 };

instead of 

    <bb 2> [local count: 1073741824]:
    _7 = BIT_FIELD_REF <x_3(D), 32, 0>;
    _8 = BIT_FIELD_REF <y_4(D), 32, 0>;
    _9 = _7 % _8;
    _10 = BIT_FIELD_REF <x_3(D), 32, 32>;
    _11 = BIT_FIELD_REF <y_4(D), 32, 32>;
    _12 = _10 % _11;
    _13 = BIT_FIELD_REF <x_3(D), 32, 64>;
    _14 = BIT_FIELD_REF <y_4(D), 32, 64>;
    _15 = _13 % _14;
    _16 = BIT_FIELD_REF <x_3(D), 32, 96>;
    _17 = BIT_FIELD_REF <y_4(D), 32, 96>;
    _18 = _16 % _17;
    _1 = {_9, _12, _15, _18};
    _2 = _1 == { 0, 0, 0, 0 };

We can adjust the test case to expect 6 times "%" on target power10_ok
specially, but I wonder if we also find this fail on some other targets which
supports vector mod, if so, one overall complete guard would be better.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[linkw at gcc dot gnu.org]

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

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #6)
> (In reply to Kewen Lin from comment #5)
> > Created attachment 53492 [details]
> > Adjust pr104992.c with vect_int_mod
> > 
> > > So it sounds like we want a generic target supports test that is true on
> > > targets (like power10) with a vector mod and key off that.  Any ideas how we
> > > can do that?
> > 
> > Add one effective target vect_int_mod for it, one quick grepping for i386
> > and aarch64 shows they don't have such support.
> 
> Heh, I was thinking of whether we could actually test whether an actual
> target supported it, but given no other arches seem to be failing this test
> case other than P10, I guess that will work. :-)

Thanks for the clarification, I guess that's doable. In this patch, I mainly
followed the existing practice vect_int_mult (there are also some similar
effective targets describing target vector support capability). With this way,
if some other arches support this in future, target owners need to add their
own conditions.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #7)
> In this patch, I mainly
> followed the existing practice vect_int_mult (there are also some similar
> effective targets describing target vector support capability). With this
> way, if some other arches support this in future, target owners need to add
> their own conditions.

Yes, and those target maintainers will notice when they add the HW support and
then see this test case FAIL, just like we did on P10.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:c28957176dc0adff6e4b8fcbe6b91f5b82900563

commit r13-2983-gc28957176dc0adff6e4b8fcbe6b91f5b82900563
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Fri Sep 30 07:16:36 2022 -0500

    rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

    As PR106516 shows, we can get unexpected gimple outputs for
    function thud on some target which supports modulus operation
    for vector int.  This patch introduces one effective target
    vect_int_mod for it, then adjusts the test case with it.

            PR testsuite/106516

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr104992.c: Adjust with vect_int_mod.
            * lib/target-supports.exp (check_effective_target_vect_int_mod):
New
            effective target.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0