Bug 98914 - [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
Summary: [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 11.0
: P1 normal
Target Milestone: 11.0
Assignee: Xionghu Luo (luoxhu@gcc.gnu.org)
URL:
Keywords: ice-on-valid-code
: 98958 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-01 11:31 UTC by Arseny Solokha
Modified: 2021-03-22 02:16 UTC (History)
5 users (show)

See Also:
Host:
Target: powerpc-*-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arseny Solokha 2021-02-01 11:31:20 UTC
gcc-11.0.0-alpha20210131 snapshot (g:98342bdd2b7085c9e7e4c9fbb07c3917a0013515) ICEs when compiling the following testcase, reduced from gcc/testsuite/gcc.target/powerpc/pr79251-run.p8.c, w/ -mvsx -Og:

void
foo (int __attribute__ ((altivec (vector__))) v)
{
  for (int k = 0; k < 1; ++k)
    v[k] = 0;
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mvsx -Og -c yo6irbnt.c
during RTL pass: expand
yo6irbnt.c: In function 'foo':
yo6irbnt.c:5:10: internal compiler error: in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
    5 |     v[k] = 0;
      |     ~~~~~^~~
0x731be0 rs6000_expand_vector_set(rtx_def*, rtx_def*, rtx_def*)
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/config/rs6000/rs6000.c:7198
0x157be60 ???
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/config/rs6000/vector.md:1251
0xceb038 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/optabs.c:7820
0xb83bfd expand_vec_set_optab_fn
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/internal-fn.c:2871
0xb83bfd expand_VEC_SET
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/internal-fn.def:148
0x954357 expand_call_stmt
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/cfgexpand.c:2748
0x954357 expand_gimple_stmt_1
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/cfgexpand.c:3843
0x954357 expand_gimple_stmt
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/cfgexpand.c:4007
0x95a01a expand_gimple_basic_block
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/cfgexpand.c:6044
0x95bb5f execute
	/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/cfgexpand.c:6728
Comment 1 Xionghu Luo (luoxhu@gcc.gnu.org) 2021-02-03 03:59:34 UTC
The type of k in the case should be "long" to reproduce the issue, 

ICE happens at 

rs6000_expand_vector_set:  gcc_assert (GET_MODE (idx) == E_SImode);


Reason is the vector index variable need be "signed int" for all vec_insert prototype. 


ELFv2 ABI:
vector signed char vec_insert (signed char, vector signed char, signed int);
vector unsigned char vec_insert (unsigned char, vector unsigned char, signed int);
vector signed int vec_insert (signed int, vector signed int, signed int);
vector unsigned int vec_insert (unsigned int, vector unsigned int, signed int);
vector signed long long vec_insert (signed long long, vector signed long long, signed int);


Not sure all targets like X86/AArch64 also has some requirements, and whether below fix reasonable to not generate IFN VEC_SET for stmt like 

VIEW_CONVERT_EXPR<unsigned char[16]>(v)[k_7] = 170;  ?


diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
index 2c78a08d3f1..dbbae270a36 100644
--- a/gcc/gimple-isel.cc
+++ b/gcc/gimple-isel.cc
@@ -77,6 +77,7 @@ gimple_expand_vec_set_expr (gimple_stmt_iterator *gsi)
       tree view_op0 = TREE_OPERAND (op0, 0);
       machine_mode outermode = TYPE_MODE (TREE_TYPE (view_op0));
       if (auto_var_in_fn_p (view_op0, cfun->decl)
+         && TYPE_MODE (TREE_TYPE (pos)) == E_SImode
          && !TREE_ADDRESSABLE (view_op0) && can_vec_set_var_idx_p (outermode))
        {
          location_t loc = gimple_location (stmt);
Comment 2 Richard Biener 2021-02-03 08:11:24 UTC
No, I think that's too restrictive.  ISTR we wanted to have "arbitrary" index modes, if the target wants just SImode it can convert_move to it, no?
Comment 3 Jakub Jelinek 2021-02-03 08:15:17 UTC
Yeah.  The requirement that the index needs to be signed int is fine for the intrinsics, but not otherwise.  And if it is an index into a vector with less than 128 elements, one shouldn't care if the index is signed or unsigned char, short, int or long long.
Comment 4 Xionghu Luo (luoxhu@gcc.gnu.org) 2021-02-04 00:38:20 UTC
*** Bug 98958 has been marked as a duplicate of this bug. ***
Comment 5 GCC Commits 2021-03-22 02:15:40 UTC
The master branch has been updated by Xiong Hu Luo <luoxhu@gcc.gnu.org>:

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

commit r11-7755-gd0a5e8e1a84bdd6ce915c3be65da8af2552cd49e
Author: Xionghu Luo <luoxhu@linux.ibm.com>
Date:   Sun Mar 21 21:14:02 2021 -0500

    rs6000: Convert the vector set variable idx to DImode [PR98914]
    
    vec_insert defines the element argument type to be signed int by ELFv2
    ABI.  When expanding a vector with a variable rtx, convert the rtx type
    to DImode to support both intrinsic usage and other callers from
    rs6000_expand_vector_init produced by v[k] = val when k is long type.
    
    gcc/ChangeLog:
    
    2021-03-21  Xionghu Luo  <luoxhu@linux.ibm.com>
    
            PR target/98914
            * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9):
            Convert idx to DImode.
            (rs6000_expand_vector_set_var_p8): Likewise.
    
    gcc/testsuite/ChangeLog:
    
    2021-03-21  Xionghu Luo  <luoxhu@linux.ibm.com>
    
            PR target/98914
            * gcc.target/powerpc/pr98914.c: New test.
Comment 6 Xionghu Luo (luoxhu@gcc.gnu.org) 2021-03-22 02:16:40 UTC
Fixed on master.