[Bug target/115493] New: gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d

[Bug target/115493] New: gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

            Bug ID: 115493
           Summary: gcc.c-torture/execute/pr94734.c fails on MVE after
                    gcc-15-1054-g202a9c8fe7d
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58428&action=edit
Code generated before the offending GCC commit (works)

As reported in https://linaro.atlassian.net/browse/GNU-1255, we are seeing

FAIL: gcc.c-torture/execute/pr94734.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr94734.c -O3 -g  execution test

after g:202a9c8fe7d
with GCC configured with:
--disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp
--with-float=hard --target=arm-eabi

and the testsuite executed with:
qemu/-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto

I'm attaching the annotated generated asm, the offending code is when calling
  if (baz (25, 4, 7) != 22)

Maybe it's a problem with how we model predicates for MVE.

[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 58429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit
Wrong code generation

[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 58431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit
vect dump OK

[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 58432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit
vect dump broken

[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2024-06-17
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.  Working with the reduced.

__attribute__((noipa)) int
baz (int n, int x, unsigned long z)
{
  int arr[16], s = 0;
  arr[12] = 42;
  for (int i = 0; i < n; i++)
    {
      if (x == (i & 0x25))
        arr[7] = i;
    }
  return arr[z];
}

int
main ()
{
  if (baz (25, 0x25, 12) != 42)
    __builtin_abort ();
  return 0;
}

When trying to reproduce for me linking fails with

/usr/bin/arm-suse-linux-gnueabi-ld: error: /tmp/cc4cHDSc.o: conflicting
architecture profiles M/A
/usr/bin/arm-suse-linux-gnueabi-ld: failed to merge target specific data of
file /tmp/cc4cHDSc.o
/usr/bin/arm-suse-linux-gnueabi-ld: error:
/home/rguenther/obj-arm-g/gcc/crtend.o: conflicting CPU architectures 21/4
/usr/bin/arm-suse-linux-gnueabi-ld: failed to merge target specific data of
file /home/rguenther/obj-arm-g/gcc/crtend.o

I configure with --target=arm-suse-linux-gnueabi --with-float=hard and have a
armv7-linux sysroot.

I'm trying to work based on cc1 and your attachments.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon <clyon at gcc dot gnu.org> ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*).  (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with-float=hard is not
sufficient).

You can't build an arm-linux-* toolchain for cortex-M.

So I suggest you build your toolchain with the flags I suggested in the
description:
with GCC configured with:
--disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp
--with-float=hard --target=arm-eabi

It shouldn't be very long since multilibs are disabled.


Alternatively, you can try to use our ABE build script:

git clone https://git.linaro.org/toolchain/abe.git
cd abe
./configure
./abe.sh --build all --target arm-eabi --extraconfigdir config/master --disable
make_docs --set languages=c,c++,lto --set
gcc_override_configure=--disable-multilib --set
gcc_override_configure=--with-mode=thumb --set
gcc_override_configure=--with-arch=armv8.1-m.main+mve.fp+fp.dp --set
gcc_override_configure=--with-float=hard --check gcc --set
'target_board_options={-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto}'
--qemu-cpu cortex-m55 --set runtestflags=execute.exp=pr94734.c

That will clone all repos (binutils-gdb, gcc, newlib, qemu), build the full
toolchain from scratch, and run the test.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The cruical difference is:

-  _60 = BIT_FIELD_REF <vect_cstore_15.37_59, 32, 0>;
-  _61 = BIT_FIELD_REF <vect_cstore_15.37_59, 32, 32>;
-  _62 = MAX_EXPR <_61, _60>;
-  _63 = BIT_FIELD_REF <vect_cstore_15.37_59, 32, 64>;
-  _64 = MAX_EXPR <_63, _62>;
-  _65 = BIT_FIELD_REF <vect_cstore_15.37_59, 32, 96>;
-  _66 = MAX_EXPR <_65, _64>;
-  _67 = _66 == -1;
-  stmp_cstore_15.38_68 = _67 ? arr__I_lsm.26_4 : _66;
+  _58 = BIT_FIELD_REF <vect_cstore_15.37_57, 32, 0>;
+  _59 = BIT_FIELD_REF <vect_cstore_15.37_57, 32, 32>;
+  _60 = BIT_FIELD_REF <vect_cstore_15.37_57, 32, 64>;
+  _61 = BIT_FIELD_REF <vect_cstore_15.37_57, 32, 96>;
+  _62 = MAX_EXPR <_58, _59>;
+  _63 = MAX_EXPR <_62, _60>;
+  _64 = MAX_EXPR <_63, _61>;
+  _65 = _61 == -1;
+  stmp_cstore_15.38_66 = _65 ? arr__I_lsm.26_4 : _61;

note how the compare against -1 uses the vector component rather the MAX
reduced value.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.0
           Priority|P3                          |P1

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 58450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58450&action=edit
patch I am testing

I'm testing this (visually confirmed it fixes the observed issue).

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:19258ca1b85bc15e3a49054eff209f4f0d1c5bee

commit r15-1392-g19258ca1b85bc15e3a49054eff209f4f0d1c5bee
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Jun 17 16:01:15 2024 +0200

    tree-optimization/115493 - fix wrong code with SLP induction cond reduction

    The following fixes a bad final value being used when doing single-lane
    SLP integer induction cond reduction vectorization.

            PR tree-optimization/115493
            * tree-vect-loop.cc (vect_create_epilog_for_reduction): Use
            the first scalar result.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed now.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

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

--- Comment #10 from Christophe Lyon <clyon at gcc dot gnu.org> ---
The test is still failing on our side. Attaching the new vect traces, hopefully
that will be enough for you?

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 58520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit
vect dump broken after r15-1392

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #11)
> Created attachment 58520 [details]
> vect dump broken after r15-1392

The IL looks OK now, I can't spot any other issue.  As I lack a runtime debug
environment it's really hard to go forward here.

Is the problem still with the

  if (baz (25, 4, 7) != 22)

part?  Can you maybe help and trace where the vectorization goes wrong?

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #13 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Yes it breaks at the same point, again we are returning an uninitialized value.
Adding annotate asm

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #14 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Created attachment 58522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit
Wrong code after r15-1392

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #13)
> Yes it breaks at the same point, again we are returning an uninitialized
> value.
> Adding annotate asm

OK, looking the fix was only half complete.  Can you try

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 347dac97e49..6f32867f85a 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -6849,7 +6849,7 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
          tree initial_def = reduc_info->reduc_initial_values[0];
          tree tmp = make_ssa_name (new_scalar_dest);
          epilog_stmt = gimple_build_assign (tmp, COND_EXPR, zcompare,
-                                            initial_def, new_temp);
+                                            initial_def, scalar_results[0]);
          gsi_insert_before (&exit_gsi, epilog_stmt, GSI_SAME_STMT);
          scalar_results[0] = tmp;
        }

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[clyon at gcc dot gnu.org]

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

--- Comment #16 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)
> OK, looking the fix was only half complete.  Can you try

It works with this, thanks!

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r15-1669-gb7ba0670a768e76e87e04cfd6a72c28c35333b54
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jun 26 19:11:04 2024 +0200

    tree-optimization/115493 - complete previous fix

    The following fixes the 2nd occurance of new_temp missed with the
    previous fix.

            PR tree-optimization/115493
            * tree-vect-loop.cc (vect_create_epilog_for_reduction): Use
            first scalar result.

[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.