[Bug target/106736] New: [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[Bug target/106736] New: [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com]

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

            Bug ID: 106736
           Summary: [13 Regression] ICE in gen_movxo, at
                    config/rs6000/mma.md:333
           Product: gcc
           Version: 13.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

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com]

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

Arseny Solokha <asolokha at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |ice-on-invalid-code

--- Comment #1 from Arseny Solokha <asolokha at gmx dot com> ---
Hit Enter too early…

gcc 13.0.0 20220821 snapshot (g:d6a39c25c05c6ed5df8ce49eda719d17e40e29bb) ICEs
when compiling gcc/testsuite/gcc.target/powerpc/pr106016.c and similar
testcases requiring -mmma support:

% powerpc-e300c3-linux-gnu-gcc-13.0.0 -c
gcc/testsuite/gcc.target/powerpc/pr106016.c
during RTL pass: expand
gcc/testsuite/gcc.target/powerpc/pr106016.c: In function 'foo':
gcc/testsuite/gcc.target/powerpc/pr106016.c:12:27: internal compiler error: in
gen_movxo, at config/rs6000/mma.md:333
   12 |   __vector_quad arr[2] = {*a, *b};
      |                           ^~
0x7d8391 gen_movxo(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/rs6000/mma.md:333
0xae1dbe rtx_insn* insn_gen_fn::operator()<rtx_def*, rtx_def*>(rtx_def*,
rtx_def*) const
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/recog.h:407
0xae1dbe emit_move_ccmode
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:3871
0xae1dbe emit_move_insn_1(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:4016
0xae222e emit_move_insn(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:4167
0xae9e11 store_expr(tree_node*, rtx_def*, int, bool, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:6342
0xaeb910 expand_assignment(tree_node*, tree_node*, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:5876
0x9aa3fa expand_gimple_stmt_1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:3946
0x9aa3fa expand_gimple_stmt
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:4044
0x9b01b4 expand_gimple_basic_block
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6096
0x9b2396 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6822

For me, it does not ICE only w/ -mcpu=power10.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-08-25
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed, this got exposed by r13-2062.

The commit expects movxo and movoo optab are only used with MMA support (or
change with vector pair support on Power10 later) and for related bif expansion
erroring.

I wonder if we want to support types __vector_quad and __vector_pair without
MMA support (or supposed to be fixed with Power10 later). If no, we need to
guard register_builtin_type under TARGET_MMA (TARGET_POWER10 later) for those
types. If yes, we may need to revisit its supports.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #2)
> I wonder if we want to support types __vector_quad and __vector_pair without
> MMA support (or supposed to be fixed with Power10 later). If no, we need to
> guard register_builtin_type under TARGET_MMA (TARGET_POWER10 later) for
> those types. If yes, we may need to revisit its supports.

No, the __vector_quad and __vector_pair types should only be used for MMA
support.  That's not to say in the future that some other different types might
produce XOmode and OOmode usage.  So basically, the "types" are limited to MMA,
but the opaque modes are not limited to MMA.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
Created attachment 53513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53513&action=edit
pr106736.diff

> No, the __vector_quad and __vector_pair types should only be used for MMA
> support.  That's not to say in the future that some other different types
> might produce XOmode and OOmode usage.  So basically, the "types" are
> limited to MMA, but the opaque modes are not limited to MMA.

Thanks for the comments! One patch guarding these types is attached, it can fix
the ICE.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #4)
> Thanks for the comments! One patch guarding these types is attached, it can
> fix the ICE.

That won't work, because that's what we used to do! :-)   In PR96125, the test
case there is compiled with -mcpu=power8, but uses a pragma/target attribute to
compile a function with -mcpu=power10/-mmma.  The problem is that built-in and
target type initialization is only done once, so we can't tell from the
explicit options being used, whether there will be a function later that uses a
pragma/target attribute, so we have to assume there will be.

Therefore, we have to always initialize them as we do now, but somehow later
catch any illegal usage.  Ideas on how to do that welcome! :-)

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #3)
> No, the __vector_quad and __vector_pair types should only be used for MMA
> support.  That's not to say in the future that some other different types
> might produce XOmode and OOmode usage.  So basically, the "types" are
> limited to MMA, but the opaque modes are not limited to MMA.

So you may wonder about the above given my latest reply in Comment #5! :-)  I
meant to say that the user should only be able to use the __vector_pair and
__vector_quad types when MMA is enabled.  That might be because they used
-mmma/-mcpu=power10 or because they're using a pragma/target attribute to
enable MMA for one specific function.

...and we actually do catch the illegal usage, but how we can fail gracefully
instead of an ICE is what we need to figure out.  Maybe similar to your
PR103353, we just need the mov[xo]o patterns to succeed temporarily so we can
fail gracefully later?

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #4)
> > Thanks for the comments! One patch guarding these types is attached, it can
> > fix the ICE.
> 
> That won't work, because that's what we used to do! :-)   In PR96125, the
> test case there is compiled with -mcpu=power8, but uses a pragma/target
> attribute to compile a function with -mcpu=power10/-mmma.  The problem is
> that built-in and target type initialization is only done once, so we can't
> tell from the explicit options being used, whether there will be a function
> later that uses a pragma/target attribute, so we have to assume there will
> be.
> 

aha, good point! Yeah, then the patch is wrong.

> Therefore, we have to always initialize them as we do now, but somehow later
> catch any illegal usage.  Ideas on how to do that welcome! :-)

> ...and we actually do catch the illegal usage, but how we can fail
> gracefully instead of an ICE is what we need to figure out.  Maybe similar
> to your PR103353, we just need the mov[xo]o patterns to succeed temporarily
> so we can fail gracefully later?

Good idea! Btw if changing the current unreachable to FAIL, it will expand as
multiple words without errors, but it's unexpected as we don't want the types
to be used like that. Maybe we can use an "error" for this kind of usage
instead of the current unreachable, will have a further look.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53513|0                           |1
        is obsolete|                            |

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
Created attachment 53522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53522&action=edit
check_opaque_types_invalid_use

Check if currently expanding gimple stmt uses opaque types unexpectedly.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
When MMA is not enabled, the movxo and movoo patterns should never be reached
at all; the __vector_{quad,pair} types should not exist, and the
{XO,OO}mode-using
code should then never be created.  So how did this happen here?

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #9)
> When MMA is not enabled,
...
> the __vector_{quad,pair} types should not exist, 

Unfortunately, target type initialization only occurs once at the very
beginning and if we don't initialize them because of the command line options
in affect at the time, then we get problems like PR96125, so we have to
initialize these types always, just like we do for built-in functions.

I also don't know of any way to attach flags to a type that says when a type is
enabled/exists and when it doesn't.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > When MMA is not enabled,
> ...
> > the __vector_{quad,pair} types should not exist, 
> 
> Unfortunately, target type initialization only occurs once at the very
> beginning

That is what indirection is for (or copying more likely, in this case).

> and if we don't initialize them because of the command line
> options in affect at the time, then we get problems like PR96125, so we have
> to initialize these types always, just like we do for built-in functions.

I don't understand?

> I also don't know of any way to attach flags to a type that says when a type
> is enabled/exists and when it doesn't.

You have to manually add code in strategic places.  Very fiddly, and very
fragile.  Or, can you do stuff in rs6000_option_override_internal?

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

--- Comment #12 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Peter Bergner from comment #10)
> > (In reply to Segher Boessenkool from comment #9)
> > > When MMA is not enabled,
> > ...
> > > the __vector_{quad,pair} types should not exist, 
> > 
> > Unfortunately, target type initialization only occurs once at the very
> > beginning
> 
> That is what indirection is for (or copying more likely, in this case).
> 
> > and if we don't initialize them because of the command line
> > options in affect at the time, then we get problems like PR96125, so we have
> > to initialize these types always, just like we do for built-in functions.
> 
> I don't understand?

Since we need to support some target pragma/attribute usage, we have to
initialize those built-in functions globally, otherwise for example assuming
command line option specifying cpu type power8, we don't initialize mma bif,
meanwhile there is one function with mma target attribute using mma bif, it
will raise error for no such bif. Although we always initialize those bifs , we
will still check their validity when expanding.

But your question makes me consider that if we can apply the similar idea for
built-in type. Now we emit error msg when expanding bif by checking its
supported (ENB...), if we can find somewhere in expander for checking built-in
type, we can add one hook there. I'll have a further look on this.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb

commit r13-4814-g282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Dec 20 21:02:08 2022 -0600

    rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled
[PR106736]

    As PR106736 shows, it's unexpected to use __vector_quad and
    __vector_pair types without MMA support, it would cause ICE
    when expanding the corresponding assignment.  We can't guard
    these built-in types registering under MMA support as Peter
    pointed out in that PR, because the registering is global,
    it doesn't work for target pragma/attribute support with MMA
    enabled.  The existing verify_type_context mentioned in [2]
    can help to make the diagnostics invalid built-in type uses
    better, but as Richard pointed out in [4], it can't deal with
    all cases.  As the discussions in [1][3], this patch is to
    check the invalid use of built-in types __vector_quad and
    __vector_pair in mov pattern of OOmode and XOmode, on the
    currently being expanded gimple assignment statement.  It
    still puts an assertion in else arm rather than just makes
    it go through, it's to ensure we can catch any other possible
    unexpected cases in time if there are.

    [1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
    [2] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html
    [3] https://gcc.gnu.org/pipermail/gcc/2022-December/240223.html
    [4] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608083.html

            PR target/106736

    gcc/ChangeLog:

            * config/rs6000/mma.md (define_expand movoo): Call function
            rs6000_opaque_type_invalid_use_p to check and emit error message
for
            the invalid use of opaque type.
            (define_expand movxo): Likewise.
            * config/rs6000/rs6000-protos.h
            (rs6000_opaque_type_invalid_use_p): New function declaration.
            (currently_expanding_gimple_stmt): New extern declaration.
            * config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): New
            function.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr106736-1.c: New test.
            * gcc.target/powerpc/pr106736-2.c: Likewise.
            * gcc.target/powerpc/pr106736-3.c: Likewise.
            * gcc.target/powerpc/pr106736-4.c: Likewise.
            * gcc.target/powerpc/pr106736-5.c: Likewise.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com]

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

--- Comment #14 from Arseny Solokha <asolokha at gmx dot com> ---
W/ gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0) I
still get this ICE when compiling
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:

% powerpc-e300c3-linux-gnu-gcc-13 -c
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c: In function 'foo1':
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:20:10: warning: GCC vector
returned by reference: non-standard ABI extension with no compatibility
guarantee [-Wpsabi]
   20 |   vec[1] = __builtin_vsx_xvcvspbf16 (vec[0]);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
during RTL pass: expand
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c: In function 'foo0':
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:9:3: internal compiler error:
in gen_movxo, at config/rs6000/mma.md:339
    9 |   asm ("#..." : "=d" (acc));
      |   ^~~
0x780433 gen_movxo(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/config/rs6000/mma.md:339
0xa767b7 rtx_insn* insn_gen_fn::operator()<rtx_def*, rtx_def*>(rtx_def*,
rtx_def*) const
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/recog.h:407
0xa767b7 emit_move_insn_1(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:4172
0xa76bbf emit_move_insn(rtx_def*, rtx_def*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:4342
0xa7ef4e store_expr(tree_node*, rtx_def*, int, bool, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:6519
0xa81703 expand_assignment(tree_node*, tree_node*, bool)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:6051
0x9479f7 expand_asm_stmt
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:3345
0x94bd29 expand_gimple_stmt_1
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:3877
0x94bd29 expand_gimple_stmt
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:4044
0x951d4e expand_gimple_basic_block
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:6096
0x953866 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:6822

I don't get the ICE when compiling the testcase from comment 0, though.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

--- Comment #15 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #14)
> W/ gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0)
> I still get this ICE when compiling
> gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:
> 

Thanks for reporting, confirmed. The function rs6000_opaque_type_invalid_use_p
only handles gassign, this failure shows another usage with asm, so we need to
teach about gasm. Since it's for a new usage, I think it's better to have one
separated bug for it. Do you mind to file a new one? 

Btw, excepting for this kind of asm usage, do you spot some others?

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com]

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

--- Comment #16 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Kewen Lin from comment #15)
> Thanks for reporting, confirmed. The function
> rs6000_opaque_type_invalid_use_p only handles gassign, this failure shows
> another usage with asm, so we need to teach about gasm. Since it's for a new
> usage, I think it's better to have one separated bug for it. Do you mind to
> file a new one? 

Sure, I've just filed PR108272.

> Btw, excepting for this kind of asm usage, do you spot some others?

Not yet. Due to the way my test setup works, I don't distinguish different
causes of the same ICE. I'll try to collect more cases by the end of the week.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

--- Comment #17 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #16)
> (In reply to Kewen Lin from comment #15)
> > Thanks for reporting, confirmed. The function
> > rs6000_opaque_type_invalid_use_p only handles gassign, this failure shows
> > another usage with asm, so we need to teach about gasm. Since it's for a new
> > usage, I think it's better to have one separated bug for it. Do you mind to
> > file a new one? 
> 
> Sure, I've just filed PR108272.

Got it, thanks!

> 
> > Btw, excepting for this kind of asm usage, do you spot some others?
> 
> Not yet. Due to the way my test setup works, I don't distinguish different
> causes of the same ICE. I'll try to collect more cases by the end of the
> week.

Many thanks!

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:92ee4e1f2792355744bf8740dccf39441b437bcf

commit r12-9029-g92ee4e1f2792355744bf8740dccf39441b437bcf
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Dec 20 21:02:08 2022 -0600

    rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled
[PR106736]

    As PR106736 shows, it's unexpected to use __vector_quad and
    __vector_pair types without MMA support, it would cause ICE
    when expanding the corresponding assignment.  We can't guard
    these built-in types registering under MMA support as Peter
    pointed out in that PR, because the registering is global,
    it doesn't work for target pragma/attribute support with MMA
    enabled.  The existing verify_type_context mentioned in [2]
    can help to make the diagnostics invalid built-in type uses
    better, but as Richard pointed out in [4], it can't deal with
    all cases.  As the discussions in [1][3], this patch is to
    check the invalid use of built-in types __vector_quad and
    __vector_pair in mov pattern of OOmode and XOmode, on the
    currently being expanded gimple assignment statement.  It
    still puts an assertion in else arm rather than just makes
    it go through, it's to ensure we can catch any other possible
    unexpected cases in time if there are.

    [1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
    [2] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html
    [3] https://gcc.gnu.org/pipermail/gcc/2022-December/240223.html
    [4] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608083.html

            PR target/106736

    gcc/ChangeLog:

            * config/rs6000/mma.md (define_expand movoo): Call function
            rs6000_opaque_type_invalid_use_p to check and emit error message
for
            the invalid use of opaque type.
            (define_expand movxo): Likewise.
            * config/rs6000/rs6000-protos.h
            (rs6000_opaque_type_invalid_use_p): New function declaration.
            (currently_expanding_gimple_stmt): New extern declaration.
            * config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): New
            function.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr106736-1.c: New test.
            * gcc.target/powerpc/pr106736-2.c: Likewise.
            * gcc.target/powerpc/pr106736-3.c: Likewise.
            * gcc.target/powerpc/pr106736-4.c: Likewise.
            * gcc.target/powerpc/pr106736-5.c: Likewise.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r11-10452-ga5c37786ac61ca41c5a227362568cfa3be7866d9
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jan 4 23:31:45 2023 -0600

    rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled
[PR106736]

    As PR106736 shows, it's unexpected to use __vector_quad and
    __vector_pair types without MMA support, it would cause ICE
    when expanding the corresponding assignment.  We can't guard
    these built-in types registering under MMA support as Peter
    pointed out in that PR, because the registering is global,
    it doesn't work for target pragma/attribute support with MMA
    enabled.  The existing verify_type_context mentioned in [2]
    can help to make the diagnostics invalid built-in type uses
    better, but as Richard pointed out in [4], it can't deal with
    all cases.  As the discussions in [1][3], this patch is to
    check the invalid use of built-in types __vector_quad and
    __vector_pair in mov pattern of OOmode and XOmode, on the
    currently being expanded gimple assignment statement.  It
    still puts an assertion in else arm rather than just makes
    it go through, it's to ensure we can catch any other possible
    unexpected cases in time if there are.

    [1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
    [2] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html
    [3] https://gcc.gnu.org/pipermail/gcc/2022-December/240223.html
    [4] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608083.html

            PR target/106736

    gcc/ChangeLog:

            * config/rs6000/mma.md (define_expand movoo): Call function
            rs6000_opaque_type_invalid_use_p to check and emit error message
for
            the invalid use of opaque type.
            (define_expand movxo): Likewise.
            * config/rs6000/rs6000-protos.h
            (rs6000_opaque_type_invalid_use_p): New function declaration.
            (currently_expanding_gimple_stmt): New extern declaration.
            * config/rs6000/rs6000.c (rs6000_opaque_type_invalid_use_p): New
            function.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr106736-1.c: New test.
            * gcc.target/powerpc/pr106736-2.c: Likewise.
            * gcc.target/powerpc/pr106736-3.c: Likewise.
            * gcc.target/powerpc/pr106736-4.c: Likewise.
            * gcc.target/powerpc/pr106736-5.c: Likewise.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:32a5510d5f419db88a0e14f3c6e4f708c0bc776d

commit r10-11149-g32a5510d5f419db88a0e14f3c6e4f708c0bc776d
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jan 4 23:32:42 2023 -0600

    rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled
[PR106736]

    As PR106736 shows, it's unexpected to use __vector_quad and
    __vector_pair types without MMA support, it would cause ICE
    when expanding the corresponding assignment.  We can't guard
    these built-in types registering under MMA support as Peter
    pointed out in that PR, because the registering is global,
    it doesn't work for target pragma/attribute support with MMA
    enabled.  The existing verify_type_context mentioned in [2]
    can help to make the diagnostics invalid built-in type uses
    better, but as Richard pointed out in [4], it can't deal with
    all cases.  As the discussions in [1][3], this patch is to
    check the invalid use of built-in types __vector_quad and
    __vector_pair in mov pattern of OOmode and XOmode, on the
    currently being expanded gimple assignment statement.  It
    still puts an assertion in else arm rather than just makes
    it go through, it's to ensure we can catch any other possible
    unexpected cases in time if there are.

    [1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
    [2] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html
    [3] https://gcc.gnu.org/pipermail/gcc/2022-December/240223.html
    [4] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608083.html

            PR target/106736

    gcc/ChangeLog:

            * config/rs6000/mma.md (define_expand movoo): Call function
            rs6000_opaque_type_invalid_use_p to check and emit error message
for
            the invalid use of opaque type.
            (define_expand movxo): Likewise.
            * config/rs6000/rs6000-protos.h
            (rs6000_opaque_type_invalid_use_p): New function declaration.
            (currently_expanding_gimple_stmt): New extern declaration.
            * config/rs6000/rs6000.c (rs6000_opaque_type_invalid_use_p): New
            function.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr106736-1.c: New test.
            * gcc.target/powerpc/pr106736-2.c: Likewise.
            * gcc.target/powerpc/pr106736-3.c: Likewise.
            * gcc.target/powerpc/pr106736-4.c: Likewise.
            * gcc.target/powerpc/pr106736-5.c: Likewise.

[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #21 from Kewen Lin <linkw at gcc dot gnu.org> ---
The ICE on the normal assignment should be fixed on release branches and trunk.
Will deal the ICE on inline asm in PR108272.