[Bug tree-optimization/104497] New: SEGV during GIMPLE pass: pre

[Bug tree-optimization/104497] New: SEGV during GIMPLE pass: pre

[jbeulich at suse dot com]

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

            Bug ID: 104497
           Summary: SEGV during GIMPLE pass: pre
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbeulich at suse dot com
  Target Milestone: ---

Compiling this

// -msse2 (on ix86) or -msse4 or -mavx
// -O0 and -O1 are okay; -Os and -O2 are not

typedef float __attribute__((mode(SF), vector_size(16))) vec_t;

extern vec_t src, inv;

void aux(vec_t);

void test(void)
{
    unsigned int i;
    vec_t y;

    for (i = 0; i < (16 / 4); ++i)
        y[i] = (i & 1 ? inv : src)[i];

    aux(y);
}

yields

$ gccver=11.2.0-base gccx -Wall -W -Os -msse2 -c simd-test2.c
during GIMPLE pass: pre
simd-test2.c: In function ‘test’:
simd-test2.c:10:6: internal compiler error: Segmentation fault
   10 | void test(void)
      |      ^~~~
0x877d21a crash_signal
        /usr/local/src/gcc-11.2.0/gcc/toplev.c:327
0x88d5bdd phi_translate_1
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1717
0x88d67f9 phi_translate
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1770
0x88d8d4b phi_translate_set
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1815
0x88d9067 compute_antic_aux
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2155
0x88da2c5 compute_antic
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2501
0x88da2c5 execute
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:4386

This same code compiles fine with gcc 10.

[Bug tree-optimization/104497] SEGV during GIMPLE pass: pre

[jbeulich at suse dot com]

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

--- Comment #1 from jbeulich at suse dot com ---
Actually, while trying to determine if there's any kind of workaround for the
actual code where the prior example was derived from, I found that this can be
further simplified:

typedef float __attribute__((mode(SF), vector_size(16))) vec_t;

extern vec_t src, inv;

void init(vec_t *x, unsigned i) {
        (*x)[i] = (i & 1 ? inv : src)[i];
}

Producing a somewhat different stack trace:

$ gccver=11.2.0-base gccx -Wall -W -Os -msse2 -c simd-test2.c
during GIMPLE pass: pre
simd-test2.c: In function ‘init’:
simd-test2.c:8:6: internal compiler error: Segmentation fault
    8 | void init(vec_t *x, unsigned i) {
      |      ^~~~
0x877d21a crash_signal
        /usr/local/src/gcc-11.2.0/gcc/toplev.c:327
0x88d39c5 pre_expr_DFS
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:825
0x88d3e45 sorted_array_from_bitmap_set
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:906
0x88d409f clean
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2009
0x88da33d compute_antic
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2519
0x88da33d execute
        /usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:4386

[Bug tree-optimization/104497] SEGV during GIMPLE pass: pre

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
<source>: In function 'test':
<source>:18:1: error: invalid RHS for gimple memory store: 'var_decl'
   18 | }
      | ^
iftmp.0

inv

# .MEM_12 = VDEF <.MEM_6>
iftmp.0 = inv;
<source>:18:1: error: invalid RHS for gimple memory store: 'var_decl'
iftmp.0

src

# .MEM_11 = VDEF <.MEM_6>
iftmp.0 = src;
during GIMPLE pass: ssa

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-02-11
           Keywords|                            |ice-on-valid-code,
                   |                            |needs-bisection
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
            Summary|SEGV during GIMPLE pass:    |[11/12 Regression] Invalid
                   |pre                         |gimple produced for
                   |                            |(A?vect:vect)[i]
   Target Milestone|---                         |11.3

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note it ICEs even at -O1 with -fchecking.

Confirmed.

Simplified testcase that fails with -O1 -fchecking:
typedef int __attribute__((vector_size(16))) vec_t;

vec_t src, inv;

vec_t test(int i)
{
    vec_t y={0};
    y[i] = (i & 1 ? inv : src)[i];
    return y;
}

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Let me have a look.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue here is that gimplification creates

      <D.1987>:
      iftmp.0 = inv;
      goto <D.1989>;
      <D.1988>:
      iftmp.0 = src;
      <D.1989>:
      _2 = VIEW_CONVERT_EXPR<int[4]>(iftmp.0)[i];

that requires a non-register iftmp.0, but we neither set DECL_NOT_GIMPLE_REG_P
nor TREE_ADDRESSABLE on iftmp.0.  If we did the iftmp.0 = {inv,src}; stmts
also would need different gimplification.

Later update_address_taken comes along and "fixes" the missing
DECL_NOT_GIMPLE_REG_P but that then makes the assigns invalid IL.

We do not support ARRAY_REF (or COMPONENT_REF) on registers.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
At -O0 we don't ICE but still have invalid

  _2 = VIEW_CONVERT_EXPR<int[4]>(iftmp.0_4)[i_7(D)];

at RTL expansion.  We're somehow recovering here, IIRC RTL expansion makes sure
to expand iftmp.0_4 to memory.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly the C++ frontend handles the COND_EXPR like

  (void) (VIEW_CONVERT_EXPR<int[4]>(y)[i] = (i & 1) != 0 ?
VIEW_CONVERT_EXPR<int[4]>(inv)[i] : VIEW_CONVERT_EXPR<int[4]>(src)[i]) >>>>>;

avoiding this issue.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS 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:3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d

commit r12-7222-g3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Feb 11 11:08:57 2022 +0100

    middle-end/104497 - gimplification of vector indexing

    The following attempts to address gimplification of

       ... = VIEW_CONVERT_EXPR<int[4]>((i & 1) != 0 ? inv : src)[i];

    which is problematic since gimplifying the base object
    ? inv : src produces a register temporary but GIMPLE does not
    really support a register as a base for an ARRAY_REF (even
    though that's not strictly validated it seems as can be seen
    at -O0).  Interestingly the C++ frontend avoids this issue
    by emitting the following GENERIC instead:

       ... = (i & 1) != 0 ? VIEW_CONVERT_EXPR<int[4]>(inv)[i] :
VIEW_CONVERT_EXPR<int[4]>(src)[i];

    The proposed patch below fixes things up when using an rvalue
    as the base is OK by emitting a copy from a register base to a
    non-register one.  The ?: as lvalue extension seems to be gone
    for C, C++ again unwraps the COND_EXPR in that case.

    2022-02-11  Richard Biener  <rguenther@suse.de>

            PR middle-end/104497
            * gimplify.cc (gimplify_compound_lval): Make sure the
            base is a non-register if needed and possible.

            * c-c++-common/torture/pr104497.c: New testcase.

[Bug tree-optimization/104497] [11 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] Invalid  |[11 Regression] Invalid
                   |gimple produced for         |gimple produced for
                   |(A?vect:vect)[i]            |(A?vect:vect)[i]
      Known to work|                            |12.0

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug tree-optimization/104497] [11 Regression] Invalid gimple produced for (A?vect:vect)[i]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r11-9785-gd34083a16b51c85b49092b0a5d9d444750f32134
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Feb 11 11:08:57 2022 +0100

    middle-end/104497 - gimplification of vector indexing

    The following attempts to address gimplification of

       ... = VIEW_CONVERT_EXPR<int[4]>((i & 1) != 0 ? inv : src)[i];

    which is problematic since gimplifying the base object
    ? inv : src produces a register temporary but GIMPLE does not
    really support a register as a base for an ARRAY_REF (even
    though that's not strictly validated it seems as can be seen
    at -O0).  Interestingly the C++ frontend avoids this issue
    by emitting the following GENERIC instead:

       ... = (i & 1) != 0 ? VIEW_CONVERT_EXPR<int[4]>(inv)[i] :
VIEW_CONVERT_EXPR<int[4]>(src)[i];

    The proposed patch below fixes things up when using an rvalue
    as the base is OK by emitting a copy from a register base to a
    non-register one.  The ?: as lvalue extension seems to be gone
    for C, C++ again unwraps the COND_EXPR in that case.

    2022-02-11  Richard Biener  <rguenther@suse.de>

            PR middle-end/104497
            * gimplify.c (gimplify_compound_lval): Make sure the
            base is a non-register if needed and possible.

            * c-c++-common/torture/pr104497.c: New testcase.

[Bug tree-optimization/104497] [11 Regression] Invalid gimple produced for (A?vect:vect)[i]

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
      Known to work|                            |11.2.1

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