| Message ID | ZfsJeqtXuqMwmv8O@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175] | expand |
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
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
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
--- 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));