public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm
@ 2024-02-27 17:19 rearnsha at gcc dot gnu.org
2024-02-27 17:23 ` [Bug middle-end/114136] " rearnsha at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-02-27 17:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Bug ID: 114136
Summary: wrong code for c23 fully anonymous arg lists on arm
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm
On arm, a fully anonymous c23-style function is called incorrectly. All
arguments are passed on the stack while the receiving function expects r0-r3 to
be used for the initial arguments.
For example,
void f (...);
void g()
{
f (1, 2, 3, 4);
}
With gcc compiles to:
g:
push {lr}
movs r0, #1
movs r1, #2
sub sp, sp, #20
movs r2, #3
movs r3, #4
stm sp, {r0, r1, r2, r3} // Arguments pushed to stack (wrong)
bl f
add sp, sp, #20
ldr pc, [sp], #4
When the correct code (eg, as produced by clang) is something like
g:
mov r0, #1
mov r1, #2
mov r2, #3
mov r3, #4
b f
compile with, eg
arm-non-eabi-gcc -O2 -c23
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
@ 2024-02-27 17:23 ` rearnsha at gcc dot gnu.org
2024-02-27 17:29 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-02-27 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2024-02-27
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
2024-02-27 17:23 ` [Bug middle-end/114136] " rearnsha at gcc dot gnu.org
@ 2024-02-27 17:29 ` pinskia at gcc dot gnu.org
2024-03-01 14:48 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-27 17:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |testsuite-fail
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The following testcases fail because of this:
FAIL: gcc.dg/c23-stdarg-4.c execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O0 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O1 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O3 -g execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -Os execution test
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
2024-02-27 17:23 ` [Bug middle-end/114136] " rearnsha at gcc dot gnu.org
2024-02-27 17:29 ` pinskia at gcc dot gnu.org
@ 2024-03-01 14:48 ` cvs-commit at gcc dot gnu.org
2024-03-02 0:39 ` cvs-commit at gcc dot gnu.org
2024-03-04 11:35 ` rearnsha at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-01 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:b5377928a2a5cd2a79eda59e2eba7d0511bf7566
commit r14-9255-gb5377928a2a5cd2a79eda59e2eba7d0511bf7566
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Mar 1 15:42:52 2024 +0100
calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR114136]
On Tue, Feb 27, 2024 at 04:41:32PM +0000, Richard Earnshaw wrote:
> On Arm the PR107453 change is causing all anonymous arguments to be
passed on the
> stack, which is incorrect per the ABI. On a target that uses
> 'pretend_outgoing_vararg_named', why is it correct to set n_named_args to
> zero? Is it enough to guard both the statements you've added with
> !targetm.calls.pretend_outgoing_args_named?
The TYPE_NO_NAMED_ARGS_STDARG_P functions (C23 fns like void foo (...) {})
have NULL type_arg_types, so the list_length (type_arg_types) isn't done
for
it, but it should be handled as if it was non-NULL but list length was 0.
So, for the
if (type_arg_types != 0)
n_named_args
= (list_length (type_arg_types)
/* Count the struct value address, if it is passed as a parm. */
+ structure_value_addr_parm);
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* If we know nothing, treat all args as named. */
n_named_args = num_actuals;
case, I think guarding it by any target hooks is wrong, although
I guess it should have been
n_named_args = structure_value_addr_parm;
instead of
n_named_args = 0;
For the second
if (type_arg_types != 0
&& targetm.calls.strict_argument_naming (args_so_far))
;
else if (type_arg_types != 0
&& ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
/* Don't include the last named arg. */
--n_named_args;
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* Treat all args as named. */
n_named_args = num_actuals;
I think we should treat those as if type_arg_types was non-NULL
with 0 elements in the list, except the --n_named_args would for
!structure_value_addr_parm lead to n_named_args = -1, I think we want
0 for that case.
2024-03-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114136
* calls.cc (expand_call): For TYPE_NO_NAMED_ARGS_STDARG_P set
n_named_args initially before INIT_CUMULATIVE_ARGS to
structure_value_addr_parm rather than 0, after it don't modify
it if strict_argument_naming and clear only if
!pretend_outgoing_varargs_named.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
` (2 preceding siblings ...)
2024-03-01 14:48 ` cvs-commit at gcc dot gnu.org
@ 2024-03-02 0:39 ` cvs-commit at gcc dot gnu.org
2024-03-04 11:35 ` rearnsha at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-02 0:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:96e6576a1ba0080e70fef4a6f9cc3129fcf6f008
commit r13-8397-g96e6576a1ba0080e70fef4a6f9cc3129fcf6f008
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Mar 1 15:42:52 2024 +0100
calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR114136]
On Tue, Feb 27, 2024 at 04:41:32PM +0000, Richard Earnshaw wrote:
> On Arm the PR107453 change is causing all anonymous arguments to be
passed on the
> stack, which is incorrect per the ABI. On a target that uses
> 'pretend_outgoing_vararg_named', why is it correct to set n_named_args to
> zero? Is it enough to guard both the statements you've added with
> !targetm.calls.pretend_outgoing_args_named?
The TYPE_NO_NAMED_ARGS_STDARG_P functions (C23 fns like void foo (...) {})
have NULL type_arg_types, so the list_length (type_arg_types) isn't done
for
it, but it should be handled as if it was non-NULL but list length was 0.
So, for the
if (type_arg_types != 0)
n_named_args
= (list_length (type_arg_types)
/* Count the struct value address, if it is passed as a parm. */
+ structure_value_addr_parm);
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* If we know nothing, treat all args as named. */
n_named_args = num_actuals;
case, I think guarding it by any target hooks is wrong, although
I guess it should have been
n_named_args = structure_value_addr_parm;
instead of
n_named_args = 0;
For the second
if (type_arg_types != 0
&& targetm.calls.strict_argument_naming (args_so_far))
;
else if (type_arg_types != 0
&& ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
/* Don't include the last named arg. */
--n_named_args;
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* Treat all args as named. */
n_named_args = num_actuals;
I think we should treat those as if type_arg_types was non-NULL
with 0 elements in the list, except the --n_named_args would for
!structure_value_addr_parm lead to n_named_args = -1, I think we want
0 for that case.
2024-03-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114136
* calls.cc (expand_call): For TYPE_NO_NAMED_ARGS_STDARG_P set
n_named_args initially before INIT_CUMULATIVE_ARGS to
structure_value_addr_parm rather than 0, after it don't modify
it if strict_argument_naming and clear only if
!pretend_outgoing_varargs_named.
(cherry picked from commit b5377928a2a5cd2a79eda59e2eba7d0511bf7566)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114136] wrong code for c23 fully anonymous arg lists on arm
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
` (3 preceding siblings ...)
2024-03-02 0:39 ` cvs-commit at gcc dot gnu.org
@ 2024-03-04 11:35 ` rearnsha at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-03-04 11:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Target Milestone|--- |13.3
Resolution|--- |FIXED
--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
fixed
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-04 11:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-27 17:19 [Bug middle-end/114136] New: wrong code for c23 fully anonymous arg lists on arm rearnsha at gcc dot gnu.org
2024-02-27 17:23 ` [Bug middle-end/114136] " rearnsha at gcc dot gnu.org
2024-02-27 17:29 ` pinskia at gcc dot gnu.org
2024-03-01 14:48 ` cvs-commit at gcc dot gnu.org
2024-03-02 0:39 ` cvs-commit at gcc dot gnu.org
2024-03-04 11:35 ` rearnsha at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).