[committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

[committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

[Jakub Jelinek]

Hi!

Like for x86-64, alpha or rs6000, m32r seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  <jakub@redhat.com>

	PR target/114175
	* config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip
	function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
	if arg.type is NULL.

--- gcc/config/m32r/m32r.cc.jj	2024-01-03 11:51:50.204472028 +0100
+++ gcc/config/m32r/m32r.cc	2024-03-20 16:12:15.841512952 +0100
@@ -1287,7 +1287,8 @@ m32r_setup_incoming_varargs (cumulative_
   if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
     gcc_assert (arg.mode != BLKmode);
 
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+      || arg.type != NULL_TREE)
     first_anon_arg = (ROUND_ADVANCE_CUM (*get_cumulative_args (cum),
 					 arg.mode, arg.type)
 		      + ROUND_ADVANCE_ARG (arg.mode, arg.type));

	Jakub

Re: [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

[Jeff Law]

On 3/20/24 10:06 AM, Jakub Jelinek wrote:
> Hi!
> 
> Like for x86-64, alpha or rs6000, m32r seems to be affected too.
> 
> Just visually checked differences in c23-stdarg-9.c assembly in a cross
> without/with the patch, committed to trunk.
> 
That fixed c23-stdarg-{6,8,9} execution tests.

jeff

Re: [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

[Jakub Jelinek]

On Wed, Mar 20, 2024 at 10:58:05AM -0600, Jeff Law wrote:
> On 3/20/24 10:06 AM, Jakub Jelinek wrote:
> > Like for x86-64, alpha or rs6000, m32r seems to be affected too.
> > 
> > Just visually checked differences in c23-stdarg-9.c assembly in a cross
> > without/with the patch, committed to trunk.
> > 
> That fixed c23-stdarg-{6,8,9} execution tests.

Thanks for these checks.  All I've done with the remaining targets
today (csky-linux epiphany-elf fr30-elf frv-linux ft32-elf m32r-elf mcore-elf
mmix-knuth-mmixware nds32-linux nios2-linux sh-linux visium-elf) was
build crosses (without binutils, so stopped shortly after building cc1),
make a copy of cc1, try expected tweaks in config/*/*.cc around the
TYPE_NO_NAMED_ARGS_STDARG_P uses unless it was clearly unnecessary,
make cc1 again and compare if the c23-stdarg-9.c assembly is any different,
if yes, try to eyeball it if the changes are desired, if the assembly is
unmodified, throw away the changes.

With the changes by others (loongarch, mips, riscv) I hope we are good on
the c23-stdarg-*.c tests on all arches.

	Jakub

Re: [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

[Jeff Law]

On 3/20/24 11:29 AM, Jakub Jelinek wrote:
> On Wed, Mar 20, 2024 at 10:58:05AM -0600, Jeff Law wrote:
>> On 3/20/24 10:06 AM, Jakub Jelinek wrote:
>>> Like for x86-64, alpha or rs6000, m32r seems to be affected too.
>>>
>>> Just visually checked differences in c23-stdarg-9.c assembly in a cross
>>> without/with the patch, committed to trunk.
>>>
>> That fixed c23-stdarg-{6,8,9} execution tests.
> 
> Thanks for these checks.  All I've done with the remaining targets
> today (csky-linux epiphany-elf fr30-elf frv-linux ft32-elf m32r-elf mcore-elf
> mmix-knuth-mmixware nds32-linux nios2-linux sh-linux visium-elf) was
> build crosses (without binutils, so stopped shortly after building cc1),
> make a copy of cc1, try expected tweaks in config/*/*.cc around the
> TYPE_NO_NAMED_ARGS_STDARG_P uses unless it was clearly unnecessary,
> make cc1 again and compare if the c23-stdarg-9.c assembly is any different,
> if yes, try to eyeball it if the changes are desired, if the assembly is
> unmodified, throw away the changes.
> 
> With the changes by others (loongarch, mips, riscv) I hope we are good on
> the c23-stdarg-*.c tests on all arches.
Forgot to note, arc-elf started passing c23-stdarg-9.c yesterday. 
Started an off-cycle run of the alpha, so figure this time tomorrow 
we'll have confirmation it's working.

Jeff