[Bug target/96791] New: ICE in convert_mode_scalar, at expr.c:412

[Bug target/96791] New: ICE in convert_mode_scalar, at expr.c:412

[asolokha at gmx dot com]

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

            Bug ID: 96791
           Summary: ICE in convert_mode_scalar, at expr.c:412
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: powerpc-*-linux-gnu

gcc-11.0.0-alpha20200823 snapshot (g:87c753ac241f25d222d46ba1ac66ceba89d6a200)
ICEs when compiling the following testcase w/ -mcpu=power10 -O1 -fno-tree-sra:

struct i0 {
  int ul;
  long long int b5;
  int lo;
  long long int rc;
};

struct i0 l3;

long int
w1 (long int xi)
{
  struct i0 eq = l3;

  return eq.rc | xi;
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power10 -O1 -fno-tree-sra -c
xwocdp87.c
during RTL pass: dse1
xwocdp87.c: In function 'w1':
xwocdp87.c:16:1: internal compiler error: in convert_mode_scalar, at expr.c:412
   16 | }
      | ^
0x5ef062 convert_mode_scalar
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/expr.c:412
0xa2da8b convert_modes(machine_mode, machine_mode, rtx_def*, int)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/expr.c:737
0xa0bde5 extract_low_bits(machine_mode, machine_mode, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/expmed.c:2421
0x15b01bd get_stored_val
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:1932
0x15b05b1 replace_read
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:2000
0x15b1b2e check_mem_read_rtx
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:2282
0x15b1b2e check_mem_read_use
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:2388
0xd21c0d note_uses(rtx_def**, void (*)(rtx_def**, void*), void*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/rtlanal.c:2030
0x15b3609 scan_insn
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:2497
0x15b3609 dse_step1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:2762
0x15b3609 rest_of_handle_dse
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:3679
0x15b3609 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/dse.c:3740

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-08-27
                 CC|                            |dje at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

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

--- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
CCing Xiong Hu, as I suspect this is related to the recent work for partially
dead stores.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
This also requires -mbig which may be implicit in the original poster's build.
But I see it failing as well.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Not the partially dead store code after all -- just a coincidence!

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |acsawdey at gcc dot gnu.org

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Nope, this is my patch that added vector pair to memcpy/memmove expansion. We
apparently don't have the right patterns defined for this to extract things
from the POImode reg that it uses.

This is the code in expr.c:

  if (GET_MODE_CLASS (from_mode) == MODE_PARTIAL_INT)
    {
      rtx new_from;
      scalar_int_mode full_mode
        = smallest_int_mode_for_size (GET_MODE_BITSIZE (from_mode));
      convert_optab ctab = unsignedp ? zext_optab : sext_optab;
      enum insn_code icode;

      icode = convert_optab_handler (ctab, full_mode, from_mode);
      gcc_assert (icode != CODE_FOR_nothing);

convert_optab_handler doesn't find anything to go from POImode to DImode, so
the assert fires.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha <asolokha at gmx dot com> ---
There's also a seemingly related case where gcc ICES in branch

  if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)

instead.

The following testcase is reduced from
gcc/testsuite/gcc.target/powerpc/pr96125.c:

void __attribute__ ((target ("cpu=power10")))
le (__vector_quad *ql)
{
  __vector_quad hg;

  __builtin_mma_xxsetaccz (&hg);
  *ql = hg;
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -c ihgsd1rx.c
during RTL pass: expand
ihgsd1rx.c: In function 'le':
ihgsd1rx.c:7:7: internal compiler error: in convert_mode_scalar, at expr.c:394
    7 |   *ql = hg;
      |   ~~~~^~~~
0x5ef679 convert_mode_scalar
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:394
0xa2f11b convert_modes(machine_mode, machine_mode, rtx_def*, int)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:737
0xa0ea12 extract_integral_bit_field
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:1961
0xa0ea12 extract_bit_field_1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:1846
0xa0f0b2 extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:2118
0xa19b88 expand_misaligned_mem_ref
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:8620
0xa284cf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:10517
0xa34c1b store_expr(tree_node*, rtx_def*, int, bool, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:5858
0xa36f21 expand_assignment(tree_node*, tree_node*, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:5594
0x90062f expand_gimple_stmt_1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:3749
0x90062f expand_gimple_stmt
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:3847
0x90655a expand_gimple_basic_block
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:5888
0x90814f execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:6572

And compiling w/ -O1 yields the following instead:

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -O1 -c ihgsd1rx.c
ihgsd1rx.c: In function 'le':
ihgsd1rx.c:8:1: error: insn does not satisfy its constraints:
    8 | }
      | ^
(insn 53 52 54 2 (set (mem/c:POI (plus:SI (reg/f:SI 1 1)
                (const_int 16 [0x10])) [3 %sfp+-80 S32 A128])
        (reg:POI 32 0 [ _1 ])) 2190 {*movpoi}
     (nil))
during RTL pass: pro_and_epilogue
ihgsd1rx.c:8:1: internal compiler error: in extract_constrain_insn, at
recog.c:2195
0x65b80d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/rtl-error.c:108
0x65b839 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/rtl-error.c:118
0x659e71 extract_constrain_insn(rtx_insn*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/recog.c:2195
0xcf731c copyprop_hardreg_forward_1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/regcprop.c:802
0xcf8101 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/regcprop.c:1181
0xd56f3d prepare_shrink_wrap
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/shrink-wrap.c:451
0xd56f3d try_shrink_wrapping(edge_def**, rtx_insn*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/shrink-wrap.c:674
0xa92dc0 thread_prologue_and_epilogue_insns()
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/function.c:5909
0xa934c6 rest_of_handle_thread_prologue_and_epilogue
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/function.c:6394
0xa934c6 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/function.c:6470

(Of course I can file a separate PR if this case is not related to the one
reported in comment 0.)

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #7 from acsawdey at gcc dot gnu.org ---
I wonder if this other case works properly when compiled with -m64. Trying to
generate a stxvp with a 32-bit address seems odd.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #8 from acsawdey at gcc dot gnu.org ---
Another small test case, reduced from my compile failure of c/c-typeck.c and
modified to provoke truncation from POImode to various other modes:

typedef int *a;
struct b { a ba; };
enum c { c1=1 };
struct e {
  union eu {
    char f_char;
    short f_short;
    int f_int;
    long f_long;
    int *f_ptr;
    long long f_ll;
  } u;
  c g;
  a h;
  b i;
};
a d(bool, bool, bool);
e j(int, e, bool, bool);
void k() {
  int l;
  for (;;) {
    e expr;
    l = sizeof(struct e);
    expr = j(l, expr, true, false);
    d(expr.u.f_char, false, __null);
    d(expr.u.f_short, false, __null);
    d(expr.u.f_int, false, __null);
    d(expr.u.f_long, false, __null);
    d(expr.u.f_ptr, false, __null);
    d(expr.u.f_ll, false, __null);
  }
}

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #9 from acsawdey at gcc dot gnu.org ---
I did post a small patch that fixes this, but more for the purpose of provoking
discussion than because I am sure it is the right way to fix this.

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553523.html

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #10 from acsawdey at gcc dot gnu.org ---
For now, disabling use of POImode for expansion of memcpy/memmove to avoid this
problem while we figure out the real fix:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553672.html

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aaron Sawdey <acsawdey@gcc.gnu.org>:

https://gcc.gnu.org/g:6b91b3e9df171970a907638d9b2e0bca1e792975

commit r11-5097-g6b91b3e9df171970a907638d9b2e0bca1e792975
Author: Aaron Sawdey <acsawdey@linux.ibm.com>
Date:   Wed Nov 4 13:54:25 2020 -0600

    Add MODE_OPAQUE

    After discussion with Richard Sandiford on IRC, he suggested adding a
    new mode class MODE_OPAQUE to deal with the problems (PR 96791) we had
    been having with POImode/PXImode in powerpc target. This patch is the
    accumulation of changes I needed to make to add this and make it useable
    for the purposes of what power10 MMA needed.

    MODE_OPAQUE modes allow you to have modes for which you can just
    define loads and stores. By design, optimization does not expect to
    know how to do arithmetic or subregs on these modes. This allows us to
    have modes for multi-register vector operations where we don't want to
    open Pandora's Box and define general arithmetic operations.

    This patch will be followed by a target specific patch to change the
    powerpc power10 MMA builtins to use opaque modes, and will also let use
    use the vector pair loads/stores defined with that in the inline expansion
    of memcpy/memmove, allowing me to fix PR 96791.

    gcc/ChangeLog
            PR target/96791
            * mode-classes.def: Add MODE_OPAQUE.
            * machmode.def: Add OPAQUE_MODE.
            * tree.def: Add OPAQUE_TYPE for types that will use
            MODE_OPAQUE.
            * doc/generic.texi: Document OPAQUE_TYPE.
            * doc/rtl.texi: Document MODE_OPAQUE.
            * machmode.h: Add OPAQUE_MODE_P().
            * genmodes.c (complete_mode): Add MODE_OPAQUE.
            (opaque_mode): New function.
            * tree.c (tree_code_size): Add OPAQUE_TYPE.
            * tree.h: Add OPAQUE_TYPE_P().
            * stor-layout.c (int_mode_for_mode): Treat MODE_OPAQUE modes
            like BLKmode.
            * ira.c (find_moveable_pseudos): Treat MODE_OPAQUE modes more
            like integer/float modes here.
            * dbxout.c (dbxout_type): Treat OPAQUE_TYPE like VOID_TYPE.
            * tree-pretty-print.c (dump_generic_node): Treat OPAQUE_TYPE
            like like other types.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[asolokha at gmx dot com]

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

--- Comment #12 from Arseny Solokha <asolokha at gmx dot com> ---
*** Bug 97963 has been marked as a duplicate of this bug. ***

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[asolokha at gmx dot com]

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

--- Comment #13 from Arseny Solokha <asolokha at gmx dot com> ---
The testcase in comment 6 still ICEs when compiled w/ -m32:

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -m32 -c wqugxu8a.c
wqugxu8a.c: In function 'test0':
wqugxu8a.c:8:1: error: insn does not satisfy its constraints:
    8 | }
      | ^
(insn 44 43 45 (set (mem/c:OO (reg/f:SI 9 9 [123]) [2 acc+0 S32 A512])
        (reg:OO 32 0)) "wqugxu8a.c":6:3 2211 {*movoo}
     (nil))
during RTL pass: shorten
wqugxu8a.c:8:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2228

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|acsawdey at gcc dot gnu.org        |bergner at gcc dot gnu.org

--- Comment #14 from Peter Bergner <bergner at gcc dot gnu.org> ---
This looks to be an attribute target issue.  When we ICE, we have:

(gdb) p TARGET_POWER10
$6 = true
(gdb) p TARGET_MMA
$7 = true
(gdb) p TARGET_VSX
$8 = false
(gdb) p TARGET_POWERPC64
$9 = false
(gdb) p TARGET_64BIT
$10 = false

TARGET_VSX being false here when POWER10/MMA is enabled is a problem.  I'll
have a look.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Why does that compiler default to -mcpu=power10?

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Oh, it's a different testcase, in comment 6.  Yeah a new PR would
have been better ;-/

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[asolokha at gmx dot com]

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

--- Comment #17 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Segher Boessenkool from comment #16)
> Oh, it's a different testcase, in comment 6.  Yeah a new PR would
> have been better ;-/

Do you want me to reopen PR97963 and copy comment 14 there until it's not too
late?

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

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

--- Comment #18 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #14)
> This looks to be an attribute target issue.  When we ICE, we have:
> 
> (gdb) p TARGET_POWER10
> $6 = true
> (gdb) p TARGET_MMA
> $7 = true
> (gdb) p TARGET_VSX
> $8 = false
> (gdb) p TARGET_POWERPC64
> $9 = false

So this happens in rs6000_option_override_internal().  We initially do have
everything set mask rs6000_isa_flags wise, but then we hit the following which
disables VSX causing our problem:

  /* Disable VSX and Altivec silently if the user switched cpus to power7 in a
     target attribute or pragma which automatically enables both options,
     unless the altivec ABI was set.  This is set by default for 64-bit, but
     not for 32-bit.  */
  if (main_target_opt != NULL && !main_target_opt->x_rs6000_altivec_abi)
    {
      TARGET_FLOAT128_TYPE = 0;
      rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC
                             | OPTION_MASK_FLOAT128_KEYWORD)
                            & ~rs6000_isa_flags_explicit);
    }

So why don't we default to the Altivec ABI with -m32 on cpus that have Altivec
and VSX units???

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #17)
> (In reply to Segher Boessenkool from comment #16)
> > Oh, it's a different testcase, in comment 6.  Yeah a new PR would
> > have been better ;-/
> 
> Do you want me to reopen PR97963 and copy comment 14 there until it's not
> too late?

Nah, it already is too late...  Just keep it in mind for the future :-)

It is easy to join two PRs.  It is very hard / annoying to separate PRs;
it is much easier if separate bugs just start out separate, so don't
piggy-back it onto a PR that you think may have to do with it (you can
always point to the existing PR!)

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #18)
> So why don't we default to the Altivec ABI with -m32 on cpus that have
> Altivec and VSX units???

History.  I'm not sure all our ABIs are compatible with vectors enabled,
either.

Since always, you have needed to use -mabi=altivec on 32-bit.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[bergner at gcc dot gnu.org]

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

--- Comment #21 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to Peter Bergner from comment #18)
> > So why don't we default to the Altivec ABI with -m32 on cpus that have
> > Altivec and VSX units???
> 
> History.  I'm not sure all our ABIs are compatible with vectors enabled,
> either.
> 
> Since always, you have needed to use -mabi=altivec on 32-bit.

So should we disable MMA for -m32, since we cannot rely on -mabi=altivec and
hence vsx being enabled for -m32?

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[meissner at gcc dot gnu.org]

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

--- Comment #22 from Michael Meissner <meissner at gcc dot gnu.org> ---
When I wrote the original in power7 days, the intent was:

If the user said -mcpu=power7 (for 32-bit) and did not explicitly set either
-mabi=altivec or -mabi=no-altivec, that -mabi=altivec would be set
automagically.

If the user said -mcpu=power7 and did specify whether the altivec was set, the
compiler would honor that request.

For 32-bit, I assume the problem may be our old friend TImode.  Other parts of
the compiler, including the generic parts of block move assume that there must
be an integer mode as large as the largest non-vector mode.  We don't provide
TImode in 32-bit, and that leads us to have to disable IEEE 128-bit hardware
support because we don't have a corresponding 128-bit integer for doing moves. 
Before OPAQUE we did define OImode and XImode, but never enabled them, and that
prevented some ICEs where the machine independent parts did not bother to check
if the get integer mode size that is n-bits returned NULL.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Changing the ABI (silently, even!) is never an expected thing.  All of the
four 32-bit ABIs we support have an AltiVec variant that isn't fully
compatible to the non-AltiVec base variant.  It would be a huge disservice
to the user to change the ABI from under his/her feet.

Anyway, patch in testing.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[bergner at gcc dot gnu.org]

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

--- Comment #24 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #23)
> Anyway, patch in testing.

Did your patch fix the problem or do we need to take another run at this?

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[segher at gcc dot gnu.org]

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

--- Comment #25 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #24)
> (In reply to Segher Boessenkool from comment #23)
> > Anyway, patch in testing.
> 
> Did your patch fix the problem or do we need to take another run at this?

I do not remember every patch from 2020.  I do still have it though :-)