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 <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3 commit r14-9535-g8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3 Author: Jakub Jelinek <ja...@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 <ja...@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.
