[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Kewen Lin --- The ICE on the normal assignment should be fixed on release branches and trunk. Will deal the ICE on inline asm in PR108272.
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #20 from CVS Commits ---
The releases/gcc-10 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:32a5510d5f419db88a0e14f3c6e4f708c0bc776d
commit r10-11149-g32a5510d5f419db88a0e14f3c6e4f708c0bc776d
Author: Kewen Lin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:a5c37786ac61ca41c5a227362568cfa3be7866d9
commit r11-10452-ga5c37786ac61ca41c5a227362568cfa3be7866d9
Author: Kewen Lin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #18 from CVS Commits ---
The releases/gcc-12 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:92ee4e1f2792355744bf8740dccf39441b437bcf
commit r12-9029-g92ee4e1f2792355744bf8740dccf39441b437bcf
Author: Kewen Lin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #17 from Kewen Lin --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #16 from Arseny Solokha --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #15 from Kewen Lin --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #14 from Arseny Solokha ---
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*) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #13 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb
commit r13-4814-g282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb
Author: Kewen Lin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #12 from Kewen Lin ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #11 from Segher Boessenkool ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #10 from Peter Bergner ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #9 from Segher Boessenkool ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Kewen Lin changed: What|Removed |Added Attachment #53513|0 |1 is obsolete|| --- Comment #8 from Kewen Lin --- Created attachment 53522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53522=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #7 from Kewen Lin --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #6 from Peter Bergner --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #5 from Peter Bergner --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Kewen Lin 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 --- Created attachment 53513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53513=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #3 from Peter Bergner --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Kewen Lin 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Arseny Solokha changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #1 from Arseny Solokha ---
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*) 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.
