[Bug middle-end/111866] New: [14 regression] ICE when compiling

[Bug middle-end/111866] New: [14 regression] ICE when compiling

[seurer at gcc dot gnu.org]

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

            Bug ID: 111866
           Summary: [14 regression] ICE when compiling
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d65e38e616e7ac8157ef04b55beb6670f2c0f142, r14-4708-gd65e38e616e7ac

FAIL: gcc.target/powerpc/p9-vec-length-full-7.c (internal compiler error: in
vect_set_loop_condition_partial_vectors, at tree-vect-loop-manip.cc:911)
FAIL: gcc.target/powerpc/p9-vec-length-full-7.c (test for excess errors)
FAIL: gcc.target/powerpc/p9-vec-length-full-run-7.c (internal compiler error:
in vect_set_loop_condition_partial_vectors, at tree-vect-loop-manip.cc:911)
FAIL: gcc.target/powerpc/p9-vec-length-full-run-7.c (test for excess errors)


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.target/powerpc/p9-vec-length-full-7.c
-fdiagnostics-plain-output -mdejagnu-cpu=power9 -O2 -ftree-vectorize
-fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll
--param=vect-partial-vector-usage=2 -ffat-lto-objects -fno-ident -S -o
p9-vec-length-full-7.s
cc1: note: disable pass tree-cunroll for functions in the range of [0,
4294967295]
during GIMPLE pass: vect
In file included from
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c:11:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h:
In function 'test_npeel_int8_t':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h:12:43:
internal compiler error: in vect_set_loop_condition_partial_vectors, at
tree-vect-loop-manip.cc:911
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length.h:4:3:
note: in expansion of macro 'test'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-7.h:20:1:
note: in expansion of macro 'TEST_ALL'
0x110c9c9b vect_set_loop_condition_partial_vectors
        /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:911
0x110c9c9b vect_set_loop_condition(loop*, edge_def*, _loop_vec_info*,
tree_node*, tree_node*, tree_node*, bool)
        /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:1366
0x110cc37b vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*,
tree_node**, tree_node**, tree_node**, int, bool, bool, tree_node**)
        /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop-manip.cc:3250
0x110ba213 vect_transform_loop(_loop_vec_info*, gimple*)
        /home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:11416
0x1110fa43 vect_transform_loops
        /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1006
0x1111042f try_vectorize_loop_1
        /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1152
0x1111042f try_vectorize_loop
        /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1182
0x111108d3 execute
        /home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1298


commit d65e38e616e7ac8157ef04b55beb6670f2c0f142 (HEAD)
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Oct 18 09:02:12 2023 +0100

    middle-end: Refactor vectorizer loop conditionals and separate out IV to
new variables

[Bug middle-end/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[tnfchris at gcc dot gnu.org]

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

--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks for reporting! I'll debug.

I suspect another case where the vectorized and scalar loop were sneakily
swapped.

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |tnfchris at gcc dot gnu.org
           Priority|P3                          |P1
   Target Milestone|---                         |14.0
          Component|middle-end                  |tree-optimization

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-18
           Keywords|                            |ice-on-valid-code
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[tnfchris at gcc dot gnu.org]

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

--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
ok, so the crash looks like it's due to rgroups_control being empty during
prologue peeling.

It looks like the loop isn't masked so LOOP_VINFO_LENS (loop_vinfo) is being
used in this case, but (!rgc->controls.is_empty ()) fails.

As far as I can tell these are only filled in by vect_get_loop_len.

It looks like after the refactoring vect_get_loop_len is not being called.  It
was expected to be called from vectorizable_store.

Debugging why it doesn't get there.

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633713.html

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

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

commit r14-4792-geb15fad3190a8b33e3e451b964ff1ecf08bbb113
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Oct 20 14:58:39 2023 +0100

    middle-end: don't pass loop_vinfo to vect_set_loop_condition during prolog
peeling

    During the refactoring I had passed loop_vinfo on to
vect_set_loop_condition
    during prolog peeling.  This parameter is unused in most cases except for
in
    vect_set_loop_condition_partial_vectors where it's behaviour depends on
whether
    loop_vinfo is NULL or not.  Apparently this code expect it to be NULL and
it
    reads the structures from a different location.

    This fixes the failing testcase which was not using the lens values
determined
    earlier in vectorizable_store because it was looking it up in the given
    loop_vinfo instead.

    gcc/ChangeLog:

            PR tree-optimization/111866
            * tree-vect-loop-manip.cc (vect_do_peeling): Pass null as vinfo to
            vect_set_loop_condition during prolog peeling.

[Bug tree-optimization/111866] [14 regression] ICE when compiling gcc.target/powerpc/p9-vec-length-full-7.c

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Fixed, sorry for the breakage!