* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
@ 2023-01-10 3:22 ` linkw at gcc dot gnu.org
2023-01-10 7:55 ` linkw at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-01-10 3:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed| |2023-01-10
Target Milestone|--- |13.0
CC| |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for reporting, confirmed!
Since ppc64le is with 64 bit configuration, it rejects -m32. But this can be
reproduced on ppc64 with option:
-m32 -mcpu=power10 -mno-altivec
Investigating.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
2023-01-10 3:22 ` [Bug target/108348] " linkw at gcc dot gnu.org
@ 2023-01-10 7:55 ` linkw at gcc dot gnu.org
2023-01-10 8:24 ` linkw at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-01-10 7:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
This is a 32 bit specific issue, the function rs6000_pass_by_reference has:
/* Allow -maltivec -mabi=no-altivec without warning. Altivec vector
modes only exist for GCC vector types if -maltivec. */
if (TARGET_32BIT && !TARGET_ALTIVEC_ABI && ALTIVEC_VECTOR_MODE (arg.mode))
{
if (TARGET_DEBUG_ARG)
fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
return 1;
}
It assumes that the altivec is on when we see those altivec vector modes, but
it doesn't hold with the option combination for this case. It returns true for
rs6000_pass_by_reference, then the following logic of generic code tries to
make a copy of the object and pass the address to the function being called, it
invokes store_expr for storing to the copy, then triggers ICE.
And targetm.calls.function_arg is too late to raise the errors.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
2023-01-10 3:22 ` [Bug target/108348] " linkw at gcc dot gnu.org
2023-01-10 7:55 ` linkw at gcc dot gnu.org
@ 2023-01-10 8:24 ` linkw at gcc dot gnu.org
2023-01-10 8:34 ` linkw at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-01-10 8:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
There seem to be two alternatives to fix this, one is to raise error in
rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
something like mma_return_type_error to avoid re-erroring; the other is to
teach the function rs6000_opaque_type_invalid_use_p about function call
statement on arguments and return values. For now, the argument and return
value checking is against the modes directly rather than the types, maybe to
unique them into rs6000_opaque_type_invalid_use_p is better?
Hi @Segher and @Peter, what do you think of this?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (2 preceding siblings ...)
2023-01-10 8:24 ` linkw at gcc dot gnu.org
@ 2023-01-10 8:34 ` linkw at gcc dot gnu.org
2023-01-10 17:08 ` bergner at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-01-10 8:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #3)
> There seem to be two alternatives to fix this, one is to raise error in
> rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
> something like mma_return_type_error to avoid re-erroring; the other is to
> teach the function rs6000_opaque_type_invalid_use_p about function call
> statement on arguments and return values. For now, the argument and return
> value checking is against the modes directly rather than the types, maybe to
> unique them into rs6000_opaque_type_invalid_use_p is better?
>
> Hi @Segher and @Peter, what do you think of this?
Ah, the later is a bad idea, as the current checking is for non MMA but the
function argument and return values checking should happen all the time. With
further thinking, the fix can be: (always return false for MMA modes, let
rs6000_function_arg to raise error msg.)
diff --git a/gcc/config/rs6000/rs6000-call.cc
b/gcc/config/rs6000/rs6000-call.cc
index 59c51fa3579..6767a1f541c 100644
--- a/gcc/config/rs6000/rs6000-call.cc
+++ b/gcc/config/rs6000/rs6000-call.cc
@@ -2013,6 +2013,11 @@ rs6000_pass_by_reference (cumulative_args_t, const
function_arg_info &arg)
{
if (TARGET_DEBUG_ARG)
fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
+ /* We do not allow MMA types being used as function arguments,
+ return false to avoid the ICE on the copying for passing by
+ reference. */
+ if (TYPE_MODE (arg.type) == OOmode || TYPE_MODE (arg.type) == XOmode)
+ return 0;
return 1;
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (3 preceding siblings ...)
2023-01-10 8:34 ` linkw at gcc dot gnu.org
@ 2023-01-10 17:08 ` bergner at gcc dot gnu.org
2023-01-11 2:51 ` linkw at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-01-10 17:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #1)
> diff --git a/gcc/config/rs6000/rs6000-call.cc
> b/gcc/config/rs6000/rs6000-call.cc
> index 59c51fa3579..6767a1f541c 100644
> --- a/gcc/config/rs6000/rs6000-call.cc
> +++ b/gcc/config/rs6000/rs6000-call.cc
> @@ -2013,6 +2013,11 @@ rs6000_pass_by_reference (cumulative_args_t, const
> function_arg_info &arg)
> {
> if (TARGET_DEBUG_ARG)
> fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
> + /* We do not allow MMA types being used as function arguments,
> + return false to avoid the ICE on the copying for passing by
> + reference. */
> + if (TYPE_MODE (arg.type) == OOmode || TYPE_MODE (arg.type) == XOmode)
> + return 0;
> return 1;
> }
This doesn't seem right. The function comment for rs6000_pass_by_reference is:
A C expression that indicates when an argument must be passed by
reference. If nonzero for an argument, a copy of that argument is
made in memory and a pointer to the argument is passed instead of
the argument itself. The pointer is passed in whatever way is
appropriate for passing a pointer to that type.
By returning false here, that seems to imply that MMA types don't have to be
passed by reference. Does that imply they can be passed by value? If so,
that's not correct, since if we have a MMA type as a function argument/return
type, it must be via a pointer to that type, so pass-by-referernce.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (4 preceding siblings ...)
2023-01-10 17:08 ` bergner at gcc dot gnu.org
@ 2023-01-11 2:51 ` linkw at gcc dot gnu.org
2023-01-18 8:35 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-01-11 2:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #1)
> > diff --git a/gcc/config/rs6000/rs6000-call.cc
> > b/gcc/config/rs6000/rs6000-call.cc
> > index 59c51fa3579..6767a1f541c 100644
> > --- a/gcc/config/rs6000/rs6000-call.cc
> > +++ b/gcc/config/rs6000/rs6000-call.cc
> > @@ -2013,6 +2013,11 @@ rs6000_pass_by_reference (cumulative_args_t, const
> > function_arg_info &arg)
> > {
> > if (TARGET_DEBUG_ARG)
> > fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
> > + /* We do not allow MMA types being used as function arguments,
> > + return false to avoid the ICE on the copying for passing by
> > + reference. */
> > + if (TYPE_MODE (arg.type) == OOmode || TYPE_MODE (arg.type) == XOmode)
> > + return 0;
> > return 1;
> > }
>
> This doesn't seem right. The function comment for rs6000_pass_by_reference
> is:
>
> A C expression that indicates when an argument must be passed by
> reference. If nonzero for an argument, a copy of that argument is
> made in memory and a pointer to the argument is passed instead of
> the argument itself. The pointer is passed in whatever way is
> appropriate for passing a pointer to that type.
>
> By returning false here, that seems to imply that MMA types don't have to be
> passed by reference. Does that imply they can be passed by value? If so,
> that's not correct, since if we have a MMA type as a function
> argument/return type, it must be via a pointer to that type, so
> pass-by-referernce.
Thanks @Peter for the comments! I think you are right. By checking the
handlings after pass-by-reference is true, I found the argument (tree_value)
would be replaced with one pointer to that type, which is permitted. I'll go
back to the approach teaching the invalid use of MMA type argument (without MMA
support) in rs6000_opaque_type_invalid_use_p then.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (5 preceding siblings ...)
2023-01-11 2:51 ` linkw at gcc dot gnu.org
@ 2023-01-18 8:35 ` cvs-commit at gcc dot gnu.org
2023-02-13 2:03 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-18 8:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #7 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:5d9529687deb9ed009361a16c02a7f6c3e2ebbf3
commit r13-5236-g5d9529687deb9ed009361a16c02a7f6c3e2ebbf3
Author: Kewen Lin <linkw@linux.ibm.com>
Date: Wed Jan 18 02:34:19 2023 -0600
rs6000: Teach rs6000_opaque_type_invalid_use_p about gcall [PR108348]
PR108348 shows one special case that MMA opaque types are
used in function arguments and treated as pass by reference,
it results in one copying from argument to a temp variable,
since this copying happens before rs6000_function_arg check,
it can cause ICE without MMA support then. This patch is to
teach function rs6000_opaque_type_invalid_use_p to check if
any function argument in a gcall stmt has the invalid use of
MMA opaque types.
btw, I checked the handling on return value, it doesn't have
this kind of issue as its checking and error emission is quite
early, so this doesn't handle function return value.
PR target/108348
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): Add
the
support for invalid uses of MMA opaque type in function arguments.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr108348-1.c: New test.
* gcc.target/powerpc/pr108348-2.c: New test.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (6 preceding siblings ...)
2023-01-18 8:35 ` cvs-commit at gcc dot gnu.org
@ 2023-02-13 2:03 ` cvs-commit at gcc dot gnu.org
2023-02-13 2:09 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-13 2:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #8 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:3c7bb6c0b0003f4e1fb52f814ad1a9a7f09573c6
commit r12-9169-g3c7bb6c0b0003f4e1fb52f814ad1a9a7f09573c6
Author: Kewen Lin <linkw@linux.ibm.com>
Date: Wed Jan 18 02:34:19 2023 -0600
rs6000: Teach rs6000_opaque_type_invalid_use_p about gcall [PR108348]
PR108348 shows one special case that MMA opaque types are
used in function arguments and treated as pass by reference,
it results in one copying from argument to a temp variable,
since this copying happens before rs6000_function_arg check,
it can cause ICE without MMA support then. This patch is to
teach function rs6000_opaque_type_invalid_use_p to check if
any function argument in a gcall stmt has the invalid use of
MMA opaque types.
btw, I checked the handling on return value, it doesn't have
this kind of issue as its checking and error emission is quite
early, so this doesn't handle function return value.
PR target/108348
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): Add
the
support for invalid uses of MMA opaque type in function arguments.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr108348-1.c: New test.
* gcc.target/powerpc/pr108348-2.c: New test.
(cherry picked from commit 5d9529687deb9ed009361a16c02a7f6c3e2ebbf3)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (7 preceding siblings ...)
2023-02-13 2:03 ` cvs-commit at gcc dot gnu.org
@ 2023-02-13 2:09 ` cvs-commit at gcc dot gnu.org
2023-02-13 2:18 ` cvs-commit at gcc dot gnu.org
2023-02-13 2:22 ` linkw at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-13 2:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #9 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:0e41d8a77887b838de5493c491f411274376227a
commit r11-10522-g0e41d8a77887b838de5493c491f411274376227a
Author: Kewen Lin <linkw@linux.ibm.com>
Date: Wed Jan 18 02:34:19 2023 -0600
rs6000: Teach rs6000_opaque_type_invalid_use_p about gcall [PR108348]
PR108348 shows one special case that MMA opaque types are
used in function arguments and treated as pass by reference,
it results in one copying from argument to a temp variable,
since this copying happens before rs6000_function_arg check,
it can cause ICE without MMA support then. This patch is to
teach function rs6000_opaque_type_invalid_use_p to check if
any function argument in a gcall stmt has the invalid use of
MMA opaque types.
btw, I checked the handling on return value, it doesn't have
this kind of issue as its checking and error emission is quite
early, so this doesn't handle function return value.
PR target/108348
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_opaque_type_invalid_use_p): Add
the
support for invalid uses of MMA opaque type in function arguments.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr108348-1.c: New test.
* gcc.target/powerpc/pr108348-2.c: New test.
(cherry picked from commit 5d9529687deb9ed009361a16c02a7f6c3e2ebbf3)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (8 preceding siblings ...)
2023-02-13 2:09 ` cvs-commit at gcc dot gnu.org
@ 2023-02-13 2:18 ` cvs-commit at gcc dot gnu.org
2023-02-13 2:22 ` linkw at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-13 2:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #10 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:7bbed35a05d735387d406afbf866384feaac21e7
commit r10-11212-g7bbed35a05d735387d406afbf866384feaac21e7
Author: Kewen Lin <linkw@linux.ibm.com>
Date: Wed Jan 18 02:34:19 2023 -0600
rs6000: Teach rs6000_opaque_type_invalid_use_p about gcall [PR108348]
PR108348 shows one special case that MMA opaque types are
used in function arguments and treated as pass by reference,
it results in one copying from argument to a temp variable,
since this copying happens before rs6000_function_arg check,
it can cause ICE without MMA support then. This patch is to
teach function rs6000_opaque_type_invalid_use_p to check if
any function argument in a gcall stmt has the invalid use of
MMA opaque types.
btw, I checked the handling on return value, it doesn't have
this kind of issue as its checking and error emission is quite
early, so this doesn't handle function return value.
PR target/108348
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_opaque_type_invalid_use_p): Add
the
support for invalid uses of MMA opaque type in function arguments.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr108348-1.c: New test.
* gcc.target/powerpc/pr108348-2.c: New test.
(cherry picked from commit 5d9529687deb9ed009361a16c02a7f6c3e2ebbf3)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
2023-01-10 2:59 [Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292 asolokha at gmx dot com
` (9 preceding siblings ...)
2023-02-13 2:18 ` cvs-commit at gcc dot gnu.org
@ 2023-02-13 2:22 ` linkw at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-02-13 2:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #11 from Kewen Lin <linkw at gcc dot gnu.org> ---
Fixed on trunk and backported to related branches.
^ permalink raw reply [flat|nested] 12+ messages in thread