[Bug target/97528] New: [10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[Bug target/97528] New: [10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[doko at debian dot org]

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

            Bug ID: 97528
           Summary: [10/11 Regression] ICE in decompose_automod_address,
                    at rtlanal.c:6298 (arm-linux-gnueabihf)
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
  Target Milestone: ---

seen on the gcc-10 branch 2020-10-11 and trunk, building firefox.

$ cat intrapred_neon.i
typedef __simd64_int16_t a;
typedef __simd64_uint16_t b;
unsigned short c;
int d;
b e;
void f() {
  unsigned short *dst = &c;
  int g = d, bw = 4;
  b dc = e;
  for (int h = 0; h < bw; h++) {
    unsigned short *i = dst;
    b j = dc;
    __builtin_neon_vst1v4hi((__builtin_neon_hi *)i, (a)j);
    dst += g;
  }
}

$ gcc -o intrapred_neon.o -c -O1 -mfpu=neon intrapred_neon.i
during RTL pass: reload
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:
In function 'aom_highbd_dc_predictor_4x4_neon':
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:589:188:
internal compiler error: in decompose_automod_address, at rtlanal.c:6298
0x6cda45 decompose_automod_address
        ../../src/gcc/rtlanal.c:6298
0x6cda45 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
        ../../src/gcc/rtlanal.c:6463
0x6cdb19 decompose_mem_address(address_info*, rtx_def*)
        ../../src/gcc/rtlanal.c:6486
0x59a67b process_address_1
        ../../src/gcc/lra-constraints.c:3374
0x59c4cd process_address
        ../../src/gcc/lra-constraints.c:3648
0x59c4cd curr_insn_transform
        ../../src/gcc/lra-constraints.c:3963
0x5a088f lra_constraints(bool)
        ../../src/gcc/lra-constraints.c:5036
0x58e7a5 lra(_IO_FILE*)
        ../../src/gcc/lra.c:2443
0x54f331 do_reload
        ../../src/gcc/ira.c:5527
0x54f331 execute
        ../../src/gcc/ira.c:5713
Please submit a full bug report,
with preprocessed source if appropriate.

gcc-10 was configured with 

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--enable-checking=yes,extra,rtl
--enable-default-pie

gcc trunk was configure with --enable-checking=yes

[Bug target/97528] [10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |ice-on-valid-code
   Target Milestone|---                         |10.3

[Bug target/97528] [10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-10-23
                 CC|                            |ktkachov at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
A better testcase, using arm_neon.h intrinsics is:
#include <arm_neon.h>

typedef __simd64_int16_t a;
typedef __simd64_uint16_t b;
unsigned short c;
int d;
b e;
void f() {
  unsigned short *dst = &c;
  int g = d, bw = 4;
  b dc = e;
  for (int h = 0; h < bw; h++) {
    unsigned short *i = dst;
    b j = dc;
    vst1_s16 ((int16_t *)i, (a) j);
    dst += g;
  }
}

I see this ICEing on 9.3.1 as well (GCC 8 branch is ok)

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have:
(insn 7 6 9 2 (set (reg:SI 114 [ _3 ])
        (ashift:SI (reg:SI 122 [ d ])
            (const_int 1 [0x1]))) "pr97528-2.c":14:9 147 {*arm_shiftsi3}
     (expr_list:REG_DEAD (reg:SI 122 [ d ])
        (nil)))
...
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
                (plus:SI (reg/v/f:SI 118 [ dst ])
                    (reg:SI 114 [ _3 ]))) [0 MEM[(short int[4] *)&c]+0 S8 A16])
        (unspec:V4HI [
                (reg:V4HI 117 [ _14 ])
            ] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
     (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
        (nil)))
and combine attempts to propagate the shift into the insn:
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
                (plus:SI (mult:SI (reg:SI 122 [ d ])
                        (const_int 2 [0x2]))
                    (reg/v/f:SI 118 [ dst ]))) [0 MEM[(short int[4] *)&c]+0 S8
A16])
        (unspec:V4HI [
                (reg:V4HI 117 [ _14 ])
            ] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
     (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
        (nil)))
That is not valid RTL, as documented:
   Currently, the compiler can only handle second operands of the
   form (plus (reg) (reg)) and (plus (reg) (const_int)), where
   the first operand of the PLUS has to be the same register as
   the first operand of the *_MODIFY.

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49587&action=edit
gcc11-pr97528.patch

Untested fix.

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:410b8f6f41920dad200cd709f9f3de8b840a995c

commit r11-5195-g410b8f6f41920dad200cd709f9f3de8b840a995c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 20 12:26:58 2020 +0100

    arm: Fix up neon_vector_mem_operand [PR97528]

    The documentation for POST_MODIFY says:
       Currently, the compiler can only handle second operands of the
       form (plus (reg) (reg)) and (plus (reg) (const_int)), where
       the first operand of the PLUS has to be the same register as
       the first operand of the *_MODIFY.
    The following testcase ICEs, because combine just attempts to simplify
    things and ends up with
    (post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1))
    but the target predicates accept it, because they only verify
    that POST_MODIFY's second operand is PLUS and the second operand
    of the PLUS is a REG.

    The following patch fixes this by performing further verification that
    the POST_MODIFY is in the form it should be.

    2020-11-20  Jakub Jelinek  <jakub@redhat.com>

            PR target/97528
            * config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY,
require
            first POST_MODIFY operand is a REG and is equal to the first
operand
            of PLUS.

            * gcc.target/arm/pr97528.c: New test.

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
                   |decompose_automod_address,  |decompose_automod_address,
                   |at rtlanal.c:6298           |at rtlanal.c:6298
                   |(arm-linux-gnueabihf)       |(arm-linux-gnueabihf)

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:05a3ab76e03ec6cff0bafb8495387b3a186785cc

commit r10-9077-g05a3ab76e03ec6cff0bafb8495387b3a186785cc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 20 12:26:58 2020 +0100

    arm: Fix up neon_vector_mem_operand [PR97528]

    The documentation for POST_MODIFY says:
       Currently, the compiler can only handle second operands of the
       form (plus (reg) (reg)) and (plus (reg) (const_int)), where
       the first operand of the PLUS has to be the same register as
       the first operand of the *_MODIFY.
    The following testcase ICEs, because combine just attempts to simplify
    things and ends up with
    (post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1))
    but the target predicates accept it, because they only verify
    that POST_MODIFY's second operand is PLUS and the second operand
    of the PLUS is a REG.

    The following patch fixes this by performing further verification that
    the POST_MODIFY is in the form it should be.

    2020-11-20  Jakub Jelinek  <jakub@redhat.com>

            PR target/97528
            * config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY,
require
            first POST_MODIFY operand is a REG and is equal to the first
operand
            of PLUS.

            * gcc.target/arm/pr97528.c: New test.

    (cherry picked from commit 410b8f6f41920dad200cd709f9f3de8b840a995c)

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Hi,

I am seeing this same fault cause a wrong-code gen on gcc-9 with the code
below:


void foo(uint16_t *dest, uint16x8_t a, unsigned long long stride)
{
   int i = 3;
   stride >>= 1;
   do {
     vst1_u16(dest, vget_low_u16(a));
     dest += stride;
     i = i - 1;
   } while (i != 0);
}

leading to:
foo:
        vst1.16 {d0}, [r0], r0
        vst1.16 {d0}, [r0], r0
        vst1.16 {d0}, [r0]
        bx      lr

which is obviously wrong. Can we backport this to gcc-9?

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
If the patch tests cleanly we should apply it to GCC 9 and 8 too (if
applicable)

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm backporting stuff to older branches in batches and don't plan to do it for
9 or 8 in the near future.  If anyone beats me with the backports, I certainly
won't mind.

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Andre Simoes Dias Vieira
<avieira@gcc.gnu.org>:

https://gcc.gnu.org/g:320d8676c770124a4baffab2d9e82224c74964ed

commit r9-9219-g320d8676c770124a4baffab2d9e82224c74964ed
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 20 12:26:58 2020 +0100

    arm: Fix up neon_vector_mem_operand [PR97528]

    The documentation for POST_MODIFY says:
       Currently, the compiler can only handle second operands of the
       form (plus (reg) (reg)) and (plus (reg) (const_int)), where
       the first operand of the PLUS has to be the same register as
       the first operand of the *_MODIFY.
    The following testcase ICEs, because combine just attempts to simplify
    things and ends up with
    (post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1))
    but the target predicates accept it, because they only verify
    that POST_MODIFY's second operand is PLUS and the second operand
    of the PLUS is a REG.

    The following patch fixes this by performing further verification that
    the POST_MODIFY is in the form it should be.

    2020-11-20  Jakub Jelinek  <jakub@redhat.com>

            PR target/97528
            * config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY,
require
            first POST_MODIFY operand is a REG and is equal to the first
operand
            of PLUS.

            * gcc.target/arm/pr97528.c: New test.

    (cherry picked from commit 410b8f6f41920dad200cd709f9f3de8b840a995c)

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira
<avieira@gcc.gnu.org>:

https://gcc.gnu.org/g:3a3460f9b79310f40265a902fb394505b947ddd1

commit r8-10751-g3a3460f9b79310f40265a902fb394505b947ddd1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 20 12:26:58 2020 +0100

    arm: Fix up neon_vector_mem_operand [PR97528]

    The documentation for POST_MODIFY says:
       Currently, the compiler can only handle second operands of the
       form (plus (reg) (reg)) and (plus (reg) (const_int)), where
       the first operand of the PLUS has to be the same register as
       the first operand of the *_MODIFY.
    The following testcase ICEs, because combine just attempts to simplify
    things and ends up with
    (post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1))
    but the target predicates accept it, because they only verify
    that POST_MODIFY's second operand is PLUS and the second operand
    of the PLUS is a REG.

    The following patch fixes this by performing further verification that
    the POST_MODIFY is in the form it should be.

    2020-11-20  Jakub Jelinek  <jakub@redhat.com>

            PR target/97528
            * config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY,
require
            first POST_MODIFY operand is a REG and is equal to the first
operand
            of PLUS.

            * gcc.target/arm/pr97528.c: New test.

    (cherry picked from commit 410b8f6f41920dad200cd709f9f3de8b840a995c)

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[avieira at gcc dot gnu.org]

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

--- Comment #12 from avieira at gcc dot gnu.org ---
@jakub: backported to gcc-8 and gcc-9. OK to close this?

[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, thanks.