[Bug target/114175] New: [14] RISC-V: Execution tests on gcc.dg/c23-stdarg-6.c

[Bug target/114175] New: [14] RISC-V: Execution tests on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com]

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

            Bug ID: 114175
           Summary: [14] RISC-V: Execution tests on gcc.dg/c23-stdarg-6.c
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

The test introduced in r14-9202-gdc30e24b76d is failing for all tested riscv
targets on linux and newlib as seen here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/570

Program received signal SIGABRT, Aborted.
0x00002aaaab3cfcb8 in __pthread_kill_implementation () from
/scratch/ewlu/ci/triage/baseline/build/sysroot/lib64/lp64d/libc.so.6
(gdb) bt
#0  0x00002aaaab3cfcb8 in __pthread_kill_implementation () from
/scratch/ewlu/ci/triage/baseline/build/sysroot/lib64/lp64d/libc.so.6
#1  0x00002aaaab3990e4 in raise () from
/scratch/ewlu/ci/triage/baseline/build/sysroot/lib64/lp64d/libc.so.6
#2  0x00002aaaab389c0c in abort () from
/scratch/ewlu/ci/triage/baseline/build/sysroot/lib64/lp64d/libc.so.6
#3  0x0000000000010f00 in main () at
../gcc/gcc/testsuite/gcc.dg/c23-stdarg-6.c:188

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does the
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646882.html
patch fix that?
The test was committed ahead exactly to find out what targets have a problem
with that.

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com]

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

--- Comment #2 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Does the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646882.html
> patch fix that?
> The test was committed ahead exactly to find out what targets have a problem
> with that.

Applied the patch on top of r14-9243-g02ca9d3f0c5. Looks like the problem is
still there.

ewlu@ewlu:/scratch/ewlu/ci/triage/compare/build-patched$
./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/ 
../gcc/gcc/testsuite/gcc.dg/c23-stdarg-6.c  -march=rv64gc -mabi=lp64d
-mtune=rocket -mcmodel=medlow   -fdiagnostics-plain-output   -std=c23
-pedantic-errors      -lm  -o ./c23-stdarg-6.exe -g
ewlu@ewlu:/scratch/ewlu/ci/triage/compare/build-patched$ QEMU_CPU=rv64
bin/qemu-riscv64 c23-stdarg-6.exe
Aborted (core dumped)

ewlu@ewlu:/scratch/ewlu/ci/triage/compare/gcc$ git diff HEAD~1
diff --git a/gcc/calls.cc b/gcc/calls.cc
index 01f44734743..21d78f9779f 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -2938,7 +2938,7 @@ expand_call (tree exp, rtx target, int ignore)
         /* 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;
+    n_named_args = structure_value_addr_parm;
   else
     /* If we know nothing, treat all args as named.  */
     n_named_args = num_actuals;
@@ -2970,14 +2970,15 @@ expand_call (tree exp, rtx target, int ignore)
      we do not have any reliable way to pass unnamed args in
      registers, so we must force them into memory.  */

-  if (type_arg_types != 0
+  if ((type_arg_types != 0 || TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
       && 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))
+  else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)
+          && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
     n_named_args = 0;
   else
     /* Treat all args as named.  */

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Edwin Lu from comment #2)
> Applied the patch on top of r14-9243-g02ca9d3f0c5. Looks like the problem is
> still there.
> -  else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
> +  else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)
> +          && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
>      n_named_args = 0;

Can you try
    ;
on the above line instead of
    n_named_args = 0;

That is the only case I'm not really sure about.
Otherwise it is likely to be something in the backend.

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com]

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

--- Comment #4 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Edwin Lu from comment #2)
> > Applied the patch on top of r14-9243-g02ca9d3f0c5. Looks like the problem is
> > still there.
> > -  else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
> > +  else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)
> > +          && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
> >      n_named_args = 0;
> 
> Can you try
>     ;
> on the above line instead of
>     n_named_args = 0;
> 
> That is the only case I'm not really sure about.
> Otherwise it is likely to be something in the backend.

so nop if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)
           && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))?

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jakub at redhat dot com            |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually seems riscv is strict_argument_naming target, so that case is never
invoked.
For strict_argument_naming n_named_args should be the number of named args,
which is
in the f case 1 (because of hidden struct return) and should be that value even
after adjustment.
Anyway, add debugging to the testcase to print the values it got, disassemble
the caller in which registers it is passing them, see where it is receiving
them.

[Bug target/114175] [14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The testcase btw performs double arithmetics and casts result to int, but it is
all whole numbers, (double) 1 + 2.0 + (double) 3 + 4.0, so it would really
surprise me if
it didn't yield the expected 10 unless there is a mismatch in arg passing.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14] RISC-V: Execution test |[13/14] RISC-V: Execution
                   |failures on                 |test failures on
                   |gcc.dg/c23-stdarg-6.c       |gcc.dg/c23-stdarg-6.c
                 CC|                            |law at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems for both
--- c23-stdarg-6.c      2024-02-28 09:26:37.091973617 +0100
+++ c23-stdarg-6a.c     2024-02-29 20:45:55.498685963 +0100
@@ -9,8 +9,8 @@ extern void abort (void);
 extern void exit (int);
 struct s { char c[1000]; };

-struct s
-f (...)
+void
+f (struct s *ret, ...)
 {
   va_list ap;
   va_start (ap);
@@ -19,10 +19,9 @@ f (...)
   r += va_arg (ap, int);
   r += va_arg (ap, double);
   va_end (ap);
-  struct s ret = {};
-  ret.c[0] = r;
-  ret.c[999] = 42;
-  return ret;
+  __builtin_memset (ret, 0, sizeof (*ret));
+  ret->c[0] = r;
+  ret->c[999] = 42;
 }

 struct s
@@ -183,7 +182,8 @@ h7 (volatile struct s x, ...)
 int
 main ()
 {
-  struct s x = f (1, 2.0, 3, 4.0);
+  struct s x;
+  f (&x, 1, 2.0, 3, 4.0);
   if (x.c[0] != 10 || x.c[999] != 42)
     abort ();
   x = g (0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0);

The arguments are passed in by the caller in a0 (the hidden struct pointer or
explicit in the other one), a1 (1), a2+a3 (2.0), a4 (3), a5+a6 (4.0).
But __floatsidf is called with original a0 in the original testcase (wrong),
while a1 in the modified.
Anyway, I doubt GCC 13 behaves different from the trunk, so there just hasn't
been a testcase for the wrong-code issue before.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess somebody should read the psABI, figure out whether it is passed right on
the caller side (without the patch or with it) or callee and debug afterwards.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palmer at gcc dot gnu.org

--- Comment #9 from palmer at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Guess somebody should read the psABI, figure out whether it is passed right
> on the caller side (without the patch or with it) or callee and debug
> afterwards.

Do you have a pointer to which call is actually failing?  I don't have a clean
tree right now and my box is backed up testing linux/glibc merges...

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> The arguments are passed in by the caller in a0 (the hidden struct pointer
> or explicit in the other one), a1 (1), a2+a3 (2.0), a4 (3), a5+a6 (4.0).

Actually a6+a7 for 4.0 instead.
Anyway the caller is identical with/without the
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646882.html
patch, so I think it is something on the callee side where it doesn't take into
account the hidden return pointer.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#3  0x0000000000010f00 in main () at
../gcc/gcc/testsuite/gcc.dg/c23-stdarg-6.c:188
in comment #c0 is the abort after the f call.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Maybe
2024-02-29  Jakub Jelinek  <jakub@redhat.com>

        PR target/114175
        * function.cc (assign_parms): Only call assign_parms_setup_varargs
        early for TYPE_NO_NAMED_ARGS_STDARG_P functions if fnargs is empty.

--- gcc/function.cc.jj  2024-01-12 13:47:20.834428745 +0100
+++ gcc/function.cc     2024-02-29 21:14:35.275889093 +0100
@@ -3650,7 +3650,8 @@ assign_parms (tree fndecl)
   assign_parms_initialize_all (&all);
   fnargs = assign_parms_augmented_arg_list (&all);

-  if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl)))
+  if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
+      && fnargs.is_empty ())
     {
       struct assign_parm_data_one data = {};
       assign_parms_setup_varargs (&all, &data, false);
?  Because if the current function returns through hidden reference, fnargs is
not empty and I'd say it should be not called before processing that hidden
reference argument.
Doesn't seem to change anything on x86_64/i686 on c23-stdarg-*.c, all still
pass,
and in cross to riscv I see difference in the f function.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Maybe not, feels like a scheduling change:
@@ -27,8 +27,8 @@ f:
        mv      s0,a0
        sw      a2,1064(sp)
        sw      a3,1068(sp)
-       sw      a0,1056(sp)
        sw      a1,1060(sp)
+       sw      a0,1056(sp)
        call    __floatsidf
        lw      a2,1064(sp)
        lw      a3,1068(sp)
@@ -100,8 +100,8 @@ g:
        sw      ra,1036(sp)
        sw      s1,1028(sp)
 .LCFI14:
-       sw      a0,1040(sp)
        mv      s4,a0
+       sw      a0,1040(sp)
        sw      a1,1044(sp)
        sw      a2,1048(sp)
        sw      a3,1052(sp)
Anyway, there are no other TYPE_NO_NAMED_ARGS_STDARG_P uses in function.cc.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #14 from palmer at gcc dot gnu.org ---
Looks like it's a problem with the struct return argument mixing with va_start
/ va_arg.  This much smaller test case still fails, and on gcc-13

$ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c
/* Test C23 variadic functions with no named parameters, or last named
   parameter with a declaration not allowed in C17.  Execution tests.  */
/* { dg-do run } */
/* { dg-options "-std=c23 -pedantic-errors" } */

#include <stdarg.h>
#include <stdio.h>

extern void abort (void);
extern void exit (int);
struct s { char c[1000]; };

struct s
f (...)
{
  va_list ap;
  va_start (ap);
  double r = va_arg (ap, int);
  va_end (ap);
  struct s ret = {};
  ret.c[0] = r;
  ret.c[999] = 42;
  return ret;
}

int
main ()
{
  struct s x = f (1);
  fprintf(stderr, "%d\n", x.c[0]);
  if (x.c[0] != 1)
    abort ();
  exit (0);
}
$ riscv64-unknown-linux-gnu-gcc gcc/testsuite/gcc.dg/c23-stdarg-6.c -o test
-std=c2x -static -O3
$ qemu-riscv64 ./test
16
Aborted

The output value seems to change from time to time, which smells like some
uninitialized access.  I'd bet we're just not properly skipping over the output
stack space in riscv_va_start().  Not quite sure where to start, though, as
ours is so much simpler than arm64 that it's going to take a bit to figure out
what's going on.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[palmer at gcc dot gnu.org]

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

--- Comment #15 from palmer at gcc dot gnu.org ---
It's a little easier to see from the float version of the code.

$ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c 
/* Test C23 variadic functions with no named parameters, or last named
   parameter with a declaration not allowed in C17.  Execution tests.  */
/* { dg-do run } */
/* { dg-options "-std=c23 -pedantic-errors" } */

#include <stdarg.h>
#include <stdio.h>

extern void abort (void);
extern void exit (int);
struct s { char c[1000]; };

struct s
f (...)
{
  va_list ap;
  va_start (ap);
  int r = va_arg (ap, double);
  va_end (ap);
  struct s ret = {};
  ret.c[0] = r;
  ret.c[999] = 42;
  return ret;
}

int
main ()
{
  struct s x = f (1.0);
  fprintf(stderr, "%d\n", x.c[0]);
  if (x.c[0] != 1)
    abort ();
  exit (0);
}
$ riscv64-unknown-linux-gnu-gcc gcc/testsuite/gcc.dg/c23-stdarg-6.c -o test
-std=c2x -static -O3
$ riscv64-unknown-linux-gnu-objdump -d test
...
0000000000010412 <main>:
...
   1042e:       850a                    mv      a0,sp
...
   10438:       112000ef                jal     1054a <f>
...
000000000001054a <f>:
   1054a:       f20507d3                fmv.d.x fa5,a0

The psABI says

    A callee with variadic arguments is responsible for copying the contents
    of registers used to pass variadic arguments to the vararg save area,
    which must be contiguous with arguments passed on the stack.

which I'm taking to mean the "1.0" is meant to be passed in a register.  It
also says

    Values are returned in the same manner as a first named argument of the
    same type would be passed. If such an argument would have been passed by
    reference, the caller allocates memory for the return value, and passes
    the address as an implicit first parameter.

So I think we're screwing up both ends of this one: the caller is passing the
return struct in a0 (losing the first arg), which the callee is obtaining the
first argument from a0 (losing the return struct).

That all very much seems like a backend bug to me.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com]

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

--- Comment #16 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to palmer from comment #15)
> It's a little easier to see from the float version of the code.
> 
> $ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c 
> /* Test C23 variadic functions with no named parameters, or last named
>    parameter with a declaration not allowed in C17.  Execution tests.  */
> /* { dg-do run } */
> /* { dg-options "-std=c23 -pedantic-errors" } */
> 
> #include <stdarg.h>
> #include <stdio.h>
> 
> extern void abort (void);
> extern void exit (int);
> struct s { char c[1000]; };
> 
> struct s
> f (...)
> {
>   va_list ap;
>   va_start (ap);
>   int r = va_arg (ap, double);
>   va_end (ap);
>   struct s ret = {};
>   ret.c[0] = r;
>   ret.c[999] = 42;
>   return ret;
> }
> 
> int
> main ()
> {
>   struct s x = f (1.0);
>   fprintf(stderr, "%d\n", x.c[0]);
>   if (x.c[0] != 1)
>     abort ();
>   exit (0);
> }
> $ riscv64-unknown-linux-gnu-gcc gcc/testsuite/gcc.dg/c23-stdarg-6.c -o test
> -std=c2x -static -O3
> $ riscv64-unknown-linux-gnu-objdump -d test
> ...
> 0000000000010412 <main>:
> ...
>    1042e:       850a                    mv      a0,sp
> ...
>    10438:       112000ef                jal     1054a <f>
> ...
> 000000000001054a <f>:
>    1054a:       f20507d3                fmv.d.x fa5,a0
> 
> The psABI says
> 
>     A callee with variadic arguments is responsible for copying the contents
>     of registers used to pass variadic arguments to the vararg save area,
>     which must be contiguous with arguments passed on the stack.
> 
> which I'm taking to mean the "1.0" is meant to be passed in a register.  It
> also says
> 
>     Values are returned in the same manner as a first named argument of the
>     same type would be passed. If such an argument would have been passed by
>     reference, the caller allocates memory for the return value, and passes
>     the address as an implicit first parameter.
> 

The psABI also says this in the paragraph before

      In the base integer calling convention, variadic arguments are passed 
      in the same manner as named arguments, with one exception. Variadic 
      arguments with 2×XLEN-bit alignment and size at most 2×XLEN bits are
      passed in an aligned register pair (i.e., the first register in the pair 
      is even-numbered), or on the stack by value if none is available. After a
      variadic argument has been passed on the stack, all future arguments will
      also be passed on the stack (i.e. the last argument register may be left 
      unused due to the aligned register pair rule).


> So I think we're screwing up both ends of this one: the caller is passing
> the return struct in a0 (losing the first arg), which the callee is
> obtaining the first argument from a0 (losing the return struct).
> 
> That all very much seems like a backend bug to me.

So if I understand correctly, there may also be a problem where it's trying to
create that named first argument but also trying to pass it as a variadic
argument.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[palmer at gcc dot gnu.org]

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

--- Comment #17 from palmer at gcc dot gnu.org ---
(In reply to Edwin Lu from comment #16)
> (In reply to palmer from comment #15)
> > It's a little easier to see from the float version of the code.
> > 
> > $ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c 
> > /* Test C23 variadic functions with no named parameters, or last named
> >    parameter with a declaration not allowed in C17.  Execution tests.  */
> > /* { dg-do run } */
> > /* { dg-options "-std=c23 -pedantic-errors" } */
> > 
> > #include <stdarg.h>
> > #include <stdio.h>
> > 
> > extern void abort (void);
> > extern void exit (int);
> > struct s { char c[1000]; };
> > 
> > struct s
> > f (...)
> > {
> >   va_list ap;
> >   va_start (ap);
> >   int r = va_arg (ap, double);
> >   va_end (ap);
> >   struct s ret = {};
> >   ret.c[0] = r;
> >   ret.c[999] = 42;
> >   return ret;
> > }
> > 
> > int
> > main ()
> > {
> >   struct s x = f (1.0);
> >   fprintf(stderr, "%d\n", x.c[0]);
> >   if (x.c[0] != 1)
> >     abort ();
> >   exit (0);
> > }
> > $ riscv64-unknown-linux-gnu-gcc gcc/testsuite/gcc.dg/c23-stdarg-6.c -o test
> > -std=c2x -static -O3
> > $ riscv64-unknown-linux-gnu-objdump -d test
> > ...
> > 0000000000010412 <main>:
> > ...
> >    1042e:       850a                    mv      a0,sp
> > ...
> >    10438:       112000ef                jal     1054a <f>
> > ...
> > 000000000001054a <f>:
> >    1054a:       f20507d3                fmv.d.x fa5,a0
> > 
> > The psABI says
> > 
> >     A callee with variadic arguments is responsible for copying the contents
> >     of registers used to pass variadic arguments to the vararg save area,
> >     which must be contiguous with arguments passed on the stack.
> > 
> > which I'm taking to mean the "1.0" is meant to be passed in a register.  It
> > also says
> > 
> >     Values are returned in the same manner as a first named argument of the
> >     same type would be passed. If such an argument would have been passed by
> >     reference, the caller allocates memory for the return value, and passes
> >     the address as an implicit first parameter.
> > 
> 
> The psABI also says this in the paragraph before
> 
>       In the base integer calling convention, variadic arguments are passed 
>       in the same manner as named arguments, with one exception. Variadic 
>       arguments with 2×XLEN-bit alignment and size at most 2×XLEN bits are
>       passed in an aligned register pair (i.e., the first register in the
> pair 
>       is even-numbered), or on the stack by value if none is available.
> After a
>       variadic argument has been passed on the stack, all future arguments
> will
>       also be passed on the stack (i.e. the last argument register may be
> left 
>       unused due to the aligned register pair rule).

Edwin and I were talking in the office a bit before he posted this.  My
interpretation (and IIUC he agrees) is that this clause doesn't apply here: the
psABI says the return value is passed as if it was a named argument, so even
though it's passed on the stack we should continue to pass small variadic
arguments in registers.

We should check with LLVM, though, just to make sure everyone is interpreting
things the same way.  GCC is inconsistent between the caller and callee here,
so we might as well match what LLVM is doing.

> > So I think we're screwing up both ends of this one: the caller is passing
> > the return struct in a0 (losing the first arg), which the callee is
> > obtaining the first argument from a0 (losing the return struct).
> > 
> > That all very much seems like a backend bug to me.
> 
> So if I understand correctly, there may also be a problem where it's trying
> to create that named first argument but also trying to pass it as a variadic
> argument.

Ya, sounds like that could very likely be the source of the bug.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[palmer at gcc dot gnu.org]

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

--- Comment #18 from palmer at gcc dot gnu.org ---
(In reply to palmer from comment #17)
> (In reply to Edwin Lu from comment #16)
> > So if I understand correctly, there may also be a problem where it's trying
> > to create that named first argument but also trying to pass it as a variadic
> > argument.
> 
> Ya, sounds like that could very likely be the source of the bug.

and to be a little less vague: I'd guess we're just treating "unnamed" as
"variadic" somewhere in the calling convention code, and that we're missing the
special case of large return values being unnamed but not variadic arguments
(even in variadic functions).

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com]

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

--- Comment #19 from Edwin Lu <ewlu at rivosinc dot com> ---
While debugging, I found that this testcase also breaks on x86_64 when
optimizations are enabled (-O1 -> -O3). 

Godbolt: https://godbolt.org/z/ecs5MPds8 

There may be other targets that fail as well. I haven't tested any others
though

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #20 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Also failing on LoongArch.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[sjames at gcc dot gnu.org]

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

--- Comment #21 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #20)
> Also failing on LoongArch.

The testcase from comment 19 or the test?

Not sure if we should move the comment 19 issue into its own PR?

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[xry111 at gcc dot gnu.org]

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

--- Comment #22 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Sam James from comment #21)
> (In reply to Xi Ruoyao from comment #20)
> > Also failing on LoongArch.
> 
> The testcase from comment 19 or the test?
> 
> Not sure if we should move the comment 19 issue into its own PR?

The c23-stdarg-6.c test itself.  Though I guess comment 19 test case will fail
too.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv, loongarch            |riscv, loongarch, x86_64

--- Comment #23 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Edwin Lu from comment #19)
> While debugging, I found that this testcase also breaks on x86_64 when
> optimizations are enabled (-O1 -> -O3). 
> 
> Godbolt: https://godbolt.org/z/ecs5MPds8 
> 
> There may be other targets that fail as well. I haven't tested any others
> though

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57714&action=edit
gcc14-pr114175.patch

Untested x86_64 fix.
Given the r13-3549 change, I'd guess most likely aarch64, alpha, arc, maybe
arm, csky, maybe epiphany, maybe fr30, maybe frv, maybe ft32, ia64, loongarch,
maybe m32r, maybe mcore, mips, mmix, maybe nds32, nios2, riscv, maybe rs6000,
maybe sh, visium need similar fix.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 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:218d17496122abe1fd831bd003f129310b32ca83

commit r14-9503-g218d17496122abe1fd831bd003f129310b32ca83
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 16 15:16:33 2024 +0100

    i386: Fix setup of incoming varargs for (...) functions which return large
aggregates [PR114175]

    The c23-stdarg-6.c testcase I've added recently apparently works fine with
    -O0 but aborts with -O1 and higher on x86_64-linux.
    The problem is in setup of incoming varargs.

    Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
    that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
    is nothing to advance, but that is not the case for (...) functions
    returning by hidden reference which have one such artificial argument.
    If the setup_incoming_varargs hook is called from the
      if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
          && fnargs.is_empty ())
        {
          struct assign_parm_data_one data = {};
          assign_parms_setup_varargs (&all, &data, false);
        }
    spot, i.e. where there is no hidden return argument passed, arg.type
    is always NULL, while when it is called in the
          if (cfun->stdarg && !DECL_CHAIN (parm))
            assign_parms_setup_varargs (&all, &data, false);
    spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be
non-NULL.
    The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
    that va_arg is used on integral types at most twice (loads 2 words),
    and because ix86_setup_incoming_varargs doesn't advance, the code saves
    just the %rdi and %rsi registers to the save area.  But that isn't correct,
    it should save %rsi and %rdx because %rdi is the hidden return argument.
    With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
    registers, so it works fine in that case.

    Now, I think we'll need the same fix also on
    aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv,
visium
    which have pretty much the similarly looking snippet in their hooks
    changed by the r13-3549 commit.
    Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
    have different changes but most likely need something similar too.
    I don't have access to most of those, could test aarch64 and rs6000 I
guess.

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

            PR target/114175
            * config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
            ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

            * gcc.dg/c23-stdarg-7.c: New test.
            * gcc.dg/c23-stdarg-8.c: New test.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv, loongarch, x86_64    |riscv, loongarch, x86_64,
                   |                            |mips

--- Comment #26 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Comment 14 test case also fails with GCC 13.2 on mips64el, but not aarch64.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
More complete testcase:
#include <stdarg.h>
struct S { int a[1024]; };
int f1 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int);
va_end (ap); return r; }
int f2 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); va_end (ap); return r; }
int f3 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); va_end (ap); return r; }
int f4 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); va_end (ap);
return r; }
int f5 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg
(ap, int); va_end (ap); return r; }
int f6 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg
(ap, int); r += va_arg (ap, int); va_end (ap); return r; }
int f7 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg
(ap, int); r += va_arg (ap, int); r += va_arg (ap, int); va_end (ap); return r;
}
int f8 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap, int); r
+= va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg
(ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int);
va_end (ap); return r; }
struct S s1 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); va_end (ap); struct S s; s.a[0] = r; return s; }
struct S s2 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); va_end (ap); struct S s; s.a[0] = r; return s; }
struct S s3 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); va_end (ap); struct S s;
s.a[0] = r; return s; }
struct S s4 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int);
va_end (ap); struct S s; s.a[0] = r; return s; }
struct S s5 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r +=
va_arg (ap, int); va_end (ap); struct S s; s.a[0] = r; return s; }
struct S s6 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r +=
va_arg (ap, int); r += va_arg (ap, int); va_end (ap); struct S s; s.a[0] = r;
return s; }
struct S s7 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r +=
va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); va_end (ap);
struct S s; s.a[0] = r; return s; }
struct S s8 (...) { int r = 0; va_list ap; va_start (ap); r += va_arg (ap,
int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r +=
va_arg (ap, int); r += va_arg (ap, int); r += va_arg (ap, int); r += va_arg
(ap, int); va_end (ap); struct S s; s.a[0] = r; return s; }
int b1 (void) { return f8 (1, 2, 3, 4, 5, 6, 7, 8); }
int b2 (void) { return s8 (1, 2, 3, 4, 5, 6, 7, 8).a[0]; }
int main () { if (f1 (1) != 1 || f2 (1, 2) != 3 || f3 (1, 2, 3) != 6 || f4 (1,
2, 3, 4) != 10 || f5 (1, 2, 3, 4, 5) != 15 || f6 (1, 2, 3, 4, 5, 6) != 21 || f7
(1, 2, 3, 4, 5, 6, 7) != 28 || f8 (1, 2, 3, 4, 5, 6, 7, 8) != 36)
__builtin_abort ();
if (s1 (1).a[0] != 1 || s2 (1, 2).a[0] != 3 || s3 (1, 2, 3).a[0] != 6 || s4 (1,
2, 3, 4).a[0] != 10 || s5 (1, 2, 3, 4, 5).a[0] != 15 || s6 (1, 2, 3, 4, 5,
6).a[0] != 21 || s7 (1, 2, 3, 4, 5, 6, 7).a[0] != 28 || s8 (1, 2, 3, 4, 5, 6,
7, 8).a[0] != 36) __builtin_abort (); }

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[xry111 at gcc dot gnu.org]

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

--- Comment #28 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
LoongArch patch (tested):
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647928.html

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57723&action=edit
gcc14-pr114175-rs6000.patch

So far just lightly tested (cross on the new testcase, scp to cfarm and
executed there before/after the patch) patch for rs6000.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Eventhough aarch64 has such !TYPE_NO_NAMED_ARGS_STDARG_P test around advancing,
most likely it is unaffected, as the hidden return pointer goes in x8 register,
while normal integral arguments go in x0-x7.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think arm is unaffected as well, while it does pass the hidden return pointer
in a register normally used for first argument, that argument should return 0
for
arm_needs_doubleword_align

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[ewlu at rivosinc dot com]

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

--- Comment #32 from Edwin Lu <ewlu at rivosinc dot com> ---
riscv patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647963.html

tested with rv64gcv-lp64d. waiting on precommit testing results

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 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:8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3

commit r14-9535-g8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:13:32 2024 +0100

    rs6000: Fix up setup_incoming_varargs [PR114175]

    The c23-stdarg-8.c test (as well as the new test below added to cover even
    more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
    as well.
    Like in the r14-9503-g218d174961 change on x86-64 we need to advance
    next_cum after the hidden return pointer argument even in case where
    there are no user arguments before ... in C23.
    The following patch does that.

    There is another TYPE_NO_NAMED_ARGS_STDARG_P use later on:
          if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
              && targetm.calls.must_pass_in_stack (arg))
            first_reg_offset += rs6000_arg_size (TYPE_MODE (arg.type),
arg.type);
    but I believe it was added there in r13-3549-g4fe34cdc unnecessarily,
    when there is no hidden return pointer argument, arg.type is NULL and
    must_pass_in_stack_var_size as well as must_pass_in_stack_var_size_or_pad
    return false in that case, and for the TYPE_NO_NAMED_ARGS_STDARG_P
    case with hidden return pointer argument that argument should have pointer
    type and it is the first argument, so must_pass_in_stack shouldn't be true
    for it either.

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

            PR target/114175
            * config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip
            rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

            * gcc.dg/c23-stdarg-9.c: New test.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 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:a185d8aeeed7a25a01505565aa61ccf8a876c6ff

commit r14-9536-ga185d8aeeed7a25a01505565aa61ccf8a876c6ff
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:14:11 2024 +0100

    alpha: Fix alpha_setup_incoming_varargs [PR114175]

    Like in the r14-9503 change on x86-64, I think Alpha also needs to
    function_arg_advance after the hidden return pointer argument if
    any.
    At least, the following patch changes the assembly of s1-s6 functions
    on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html
    c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...)
    the ... args are passed in 16..21 registers and then on the stack,
    while for struct S s8 (...) have hidden return pointer passed in 16
    register and ... args in 17..21 registers and then on the stack, and
    seems without this patch the incoming varargs setup does the wrong thing
    (but I can't test on alpha easily).

    Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not
    trying to change all targets together because such a change clearly isn't
    needed e.g. for targets which use special register for the hidden return
    pointer.

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

            PR target/114175
            * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
            function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #35 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

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

commit r14-9538-gc1fd4589c2bf9fd8409d51b94df219cb75107762
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Mon Mar 18 17:18:34 2024 +0800

    LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

    We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
    arguments and there is nothing to advance, but that is not the case
    for (...) functions returning by hidden reference which have one such
    artificial argument.  This is causing gcc.dg/c23-stdarg-6.c and
    gcc.dg/c23-stdarg-8.c to fail.

    Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

    gcc/ChangeLog:

            PR target/114175
            * config/loongarch/loongarch.cc
            (loongarch_setup_incoming_varargs): Only skip
            loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
            functions if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[xry111 at gcc dot gnu.org]

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

--- Comment #36 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Do we need a backport to releases/gcc-13?

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #37 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:1f257714674cd8fd69db7367aecdd09b672d1db7

commit r14-9539-g1f257714674cd8fd69db7367aecdd09b672d1db7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:49:59 2024 +0100

    arc: Fix up arc_setup_incoming_varargs [PR114175]

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

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

            PR target/114175
            * config/arc/arc.cc (arc_setup_incoming_varargs): Only skip
            arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[jakub at gcc dot gnu.org]

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

--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #36)
> Do we need a backport to releases/gcc-13?

Yes, but I'd wait a little bit with that.

BTW, as expected, ia64 seems to be unaffected, and I don't have trees built for
the remaining targets.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #39 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Edwin Lu <ewlu@gcc.gnu.org>:

https://gcc.gnu.org/g:60586710b0646efdbbd77a7f53b93fb5edb87a61

commit r14-9552-g60586710b0646efdbbd77a7f53b93fb5edb87a61
Author: Edwin Lu <ewlu@rivosinc.com>
Date:   Mon Mar 18 11:43:41 2024 -0700

    RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

    We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments
and
    there is nothing to advance, but that is not the case for (...) functions
    returning by hidden reference which have one such artificial argument.
    This causes gcc.dg/c23-stdarg-[68].c to fail

    Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
    explains

    Tested on linux rv64gcv.

    gcc/ChangeLog:

            PR target/114175
            * config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
            riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[xry111 at gcc dot gnu.org]

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

--- Comment #40 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
mips patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648070.html
(tested with -mabi=64)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #41 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:68eca9b6aefeb40bdd4c55e42528cb32d1e2935b

commit r14-9573-g68eca9b6aefeb40bdd4c55e42528cb32d1e2935b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:08 2024 +0100

    csky: Fix up csky_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, csky 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/csky/csky.cc (csky_setup_incoming_varargs): Only skip
            csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #42 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:b089ceb365e5132e4b2a8acfb18127bbee2d0d00

commit r14-9574-gb089ceb365e5132e4b2a8acfb18127bbee2d0d00
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:21 2024 +0100

    epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, epiphany 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/epiphany/epiphany.cc (epiphany_setup_incoming_varargs):
Only
            skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #43 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:22612a8b5e0853c530f98fc7c0d6f6812b36518d

commit r14-9575-g22612a8b5e0853c530f98fc7c0d6f6812b36518d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:32 2024 +0100

    ft32: Fix up ft32_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, ft32 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/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip
            function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #44 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:921eb457c5b105bcd84eaeac22067e9b03d5b9d1

commit r14-9576-g921eb457c5b105bcd84eaeac22067e9b03d5b9d1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:43 2024 +0100

    m32r: Fix up m32r_setup_incoming_varargs [PR114175]

    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.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #45 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:b22a9c7dd29a14a217de8b86d3e100e4e8b7785e

commit r14-9577-gb22a9c7dd29a14a217de8b86d3e100e4e8b7785e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:56 2024 +0100

    nds32: Fix up nds32_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, nds32 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/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip
            function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #46 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:4c9d2810908004b7e04599b426aca5ee1bd16735

commit r14-9578-g4c9d2810908004b7e04599b426aca5ee1bd16735
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 17:00:08 2024 +0100

    nios2: Fix up nios2_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, nios2 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/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
            nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #47 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:b05ee9b69e4644cefbb94a768c4ea302fd44b934

commit r14-9579-gb05ee9b69e4644cefbb94a768c4ea302fd44b934
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 17:00:51 2024 +0100

    visium: Fix up visium_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, visium 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/visium/visium.cc (visium_setup_incoming_varargs): Only
skip
            TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #48 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:6fc84f680d098f82c1c43435fdb206099f0df4df

commit r14-9728-g6fc84f680d098f82c1c43435fdb206099f0df4df
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Wed Mar 20 15:09:21 2024 +0800

    mips: Fix C23 (...) functions returning large aggregates [PR114175]

    We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
    arguments and there is nothing to advance, but that is not the case
    for (...) functions returning by hidden reference which have one such
    artificial argument.  This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
    fail.

    Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

    gcc/ChangeLog:

            PR target/114175
            * config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
            mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
            functions if arg.type is NULL.

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #49 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:4e0a922db4dadaef704c68ed26693667903c5d0c

commit r13-8508-g4e0a922db4dadaef704c68ed26693667903c5d0c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 16 15:16:33 2024 +0100

    i386: Fix setup of incoming varargs for (...) functions which return large
aggregates [PR114175]

    The c23-stdarg-6.c testcase I've added recently apparently works fine with
    -O0 but aborts with -O1 and higher on x86_64-linux.
    The problem is in setup of incoming varargs.

    Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
    that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
    is nothing to advance, but that is not the case for (...) functions
    returning by hidden reference which have one such artificial argument.
    If the setup_incoming_varargs hook is called from the
      if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
          && fnargs.is_empty ())
        {
          struct assign_parm_data_one data = {};
          assign_parms_setup_varargs (&all, &data, false);
        }
    spot, i.e. where there is no hidden return argument passed, arg.type
    is always NULL, while when it is called in the
          if (cfun->stdarg && !DECL_CHAIN (parm))
            assign_parms_setup_varargs (&all, &data, false);
    spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be
non-NULL.
    The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
    that va_arg is used on integral types at most twice (loads 2 words),
    and because ix86_setup_incoming_varargs doesn't advance, the code saves
    just the %rdi and %rsi registers to the save area.  But that isn't correct,
    it should save %rsi and %rdx because %rdi is the hidden return argument.
    With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
    registers, so it works fine in that case.

    Now, I think we'll need the same fix also on
    aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv,
visium
    which have pretty much the similarly looking snippet in their hooks
    changed by the r13-3549 commit.
    Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
    have different changes but most likely need something similar too.
    I don't have access to most of those, could test aarch64 and rs6000 I
guess.

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

            PR target/114175
            * config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
            ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

            * gcc.dg/c23-stdarg-7.c: New test.
            * gcc.dg/c23-stdarg-8.c: New test.

    (cherry picked from commit 218d17496122abe1fd831bd003f129310b32ca83)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #50 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:af189fa9c2c4a0c8230f308e1934f046df3e80f7

commit r13-8509-gaf189fa9c2c4a0c8230f308e1934f046df3e80f7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:13:32 2024 +0100

    rs6000: Fix up setup_incoming_varargs [PR114175]

    The c23-stdarg-8.c test (as well as the new test below added to cover even
    more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
    as well.
    Like in the r14-9503-g218d174961 change on x86-64 we need to advance
    next_cum after the hidden return pointer argument even in case where
    there are no user arguments before ... in C23.
    The following patch does that.

    There is another TYPE_NO_NAMED_ARGS_STDARG_P use later on:
          if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
              && targetm.calls.must_pass_in_stack (arg))
            first_reg_offset += rs6000_arg_size (TYPE_MODE (arg.type),
arg.type);
    but I believe it was added there in r13-3549-g4fe34cdc unnecessarily,
    when there is no hidden return pointer argument, arg.type is NULL and
    must_pass_in_stack_var_size as well as must_pass_in_stack_var_size_or_pad
    return false in that case, and for the TYPE_NO_NAMED_ARGS_STDARG_P
    case with hidden return pointer argument that argument should have pointer
    type and it is the first argument, so must_pass_in_stack shouldn't be true
    for it either.

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

            PR target/114175
            * config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip
            rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

            * gcc.dg/c23-stdarg-9.c: New test.

    (cherry picked from commit 8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #51 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:d3faceaa7a18657cc73dff1405a54834e390624b

commit r13-8510-gd3faceaa7a18657cc73dff1405a54834e390624b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:14:11 2024 +0100

    alpha: Fix alpha_setup_incoming_varargs [PR114175]

    Like in the r14-9503 change on x86-64, I think Alpha also needs to
    function_arg_advance after the hidden return pointer argument if
    any.
    At least, the following patch changes the assembly of s1-s6 functions
    on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html
    c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...)
    the ... args are passed in 16..21 registers and then on the stack,
    while for struct S s8 (...) have hidden return pointer passed in 16
    register and ... args in 17..21 registers and then on the stack, and
    seems without this patch the incoming varargs setup does the wrong thing
    (but I can't test on alpha easily).

    Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not
    trying to change all targets together because such a change clearly isn't
    needed e.g. for targets which use special register for the hidden return
    pointer.

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

            PR target/114175
            * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
            function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit a185d8aeeed7a25a01505565aa61ccf8a876c6ff)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #52 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:097999338bc0e298290ec965c946f69f2237729a

commit r13-8511-g097999338bc0e298290ec965c946f69f2237729a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 19 09:49:59 2024 +0100

    arc: Fix up arc_setup_incoming_varargs [PR114175]

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

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

            PR target/114175
            * config/arc/arc.cc (arc_setup_incoming_varargs): Only skip
            arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit 1f257714674cd8fd69db7367aecdd09b672d1db7)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #53 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:06f9476a60bcf2d206b7b86e68ea433954f91f20

commit r13-8513-g06f9476a60bcf2d206b7b86e68ea433954f91f20
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:08 2024 +0100

    csky: Fix up csky_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, csky 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/csky/csky.cc (csky_setup_incoming_varargs): Only skip
            csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit 68eca9b6aefeb40bdd4c55e42528cb32d1e2935b)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #54 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:fce980ba3802e1adc68cb34ae81d17bc8c9d13b9

commit r13-8514-gfce980ba3802e1adc68cb34ae81d17bc8c9d13b9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:21 2024 +0100

    epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, epiphany 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/epiphany/epiphany.cc (epiphany_setup_incoming_varargs):
Only
            skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit b089ceb365e5132e4b2a8acfb18127bbee2d0d00)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #55 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:a2565fbb722f9ea9a990286b72ae1a95145af910

commit r13-8515-ga2565fbb722f9ea9a990286b72ae1a95145af910
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:32 2024 +0100

    ft32: Fix up ft32_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, ft32 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/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip
            function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit 22612a8b5e0853c530f98fc7c0d6f6812b36518d)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #56 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:f3af5a241c820e564ef13614ae0ea7a57237bd50

commit r13-8516-gf3af5a241c820e564ef13614ae0ea7a57237bd50
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:43 2024 +0100

    m32r: Fix up m32r_setup_incoming_varargs [PR114175]

    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.

    (cherry picked from commit 921eb457c5b105bcd84eaeac22067e9b03d5b9d1)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #57 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:91092c30eda6777e33705a66a2c3049d4a18569d

commit r13-8517-g91092c30eda6777e33705a66a2c3049d4a18569d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 16:59:56 2024 +0100

    nds32: Fix up nds32_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, nds32 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/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip
            function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
            if arg.type is NULL.

    (cherry picked from commit b22a9c7dd29a14a217de8b86d3e100e4e8b7785e)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #58 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:02f66c40fb626656b924c1c7af3b5ededf8963e5

commit r13-8518-g02f66c40fb626656b924c1c7af3b5ededf8963e5
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 17:00:08 2024 +0100

    nios2: Fix up nios2_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, nios2 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/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
            nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

    (cherry picked from commit 4c9d2810908004b7e04599b426aca5ee1bd16735)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #59 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:01397f789866198ad4fae3893d8f6b0a1d96cd96

commit r13-8519-g01397f789866198ad4fae3893d8f6b0a1d96cd96
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 17:00:51 2024 +0100

    visium: Fix up visium_setup_incoming_varargs [PR114175]

    Like for x86-64, alpha or rs6000, visium 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/visium/visium.cc (visium_setup_incoming_varargs): Only
skip
            TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL.

    (cherry picked from commit b05ee9b69e4644cefbb94a768c4ea302fd44b934)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #60 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

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

commit r13-8526-gb73a6a20113ca607cf3073c751698b12aa167881
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Mon Mar 18 17:18:34 2024 +0800

    LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

    We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
    arguments and there is nothing to advance, but that is not the case
    for (...) functions returning by hidden reference which have one such
    artificial argument.  This is causing gcc.dg/c23-stdarg-6.c and
    gcc.dg/c23-stdarg-8.c to fail.

    Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

    gcc/ChangeLog:

            PR target/114175
            * config/loongarch/loongarch.cc
            (loongarch_setup_incoming_varargs): Only skip
            loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
            functions if arg.type is NULL.

    (cherry picked from commit c1fd4589c2bf9fd8409d51b94df219cb75107762)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #61 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:1ab646f678a9d47b338424ed69e9ae5d774b06ae

commit r13-8527-g1ab646f678a9d47b338424ed69e9ae5d774b06ae
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Wed Mar 20 15:09:21 2024 +0800

    mips: Fix C23 (...) functions returning large aggregates [PR114175]

    We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
    arguments and there is nothing to advance, but that is not the case
    for (...) functions returning by hidden reference which have one such
    artificial argument.  This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
    fail.

    Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

    gcc/ChangeLog:

            PR target/114175
            * config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
            mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
            functions if arg.type is NULL.

    (cherry picked from commit 6fc84f680d098f82c1c43435fdb206099f0df4df)

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #62 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Edwin Lu <ewlu@gcc.gnu.org>:

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

commit r13-8579-gc4eff4ece764d836eb7ee0c0163780d100471730
Author: Edwin Lu <ewlu@rivosinc.com>
Date:   Mon Mar 18 11:43:41 2024 -0700

    RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

    We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments
and
    there is nothing to advance, but that is not the case for (...) functions
    returning by hidden reference which have one such artificial argument.
    This causes gcc.dg/c23-stdarg-[68].c to fail

    Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
    explains

    Tested on linux rv64gcv.

    gcc/ChangeLog:

            PR target/114175
            * config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
            riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions
            if arg.type is NULL

    (cherry picked from commit 60586710b0646efdbbd77a7f53b93fb5edb87a61)