https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #16 from Kai Tietz <ktietz at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to David Grayson from comment #14)
>
> > Does anyone have an idea of how to fix this bug for real? What values
> > should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> > have on Windows, and should they be controllable from the command-line?
> > Where do they get set?
> >
> > --David
>
> Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
> (gdb) watch x_rtl.preferred_stack_boundary
>
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
>
> (gdb) r
> Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
>
> Old value = 0
> New value = 32
> 0x0000000000b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0
> <x_rtl>) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
> 6636 preferred_stack_boundary = STACK_BOUNDARY;
>
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
>
> Old value = 32
> New value = 128
> emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair<rtx_def*, machine_mode>*) ()
> at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> 4744 if (outmode != VOIDmode)
>
> (gdb) list
> 4739 if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
> 4740 crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
> 4741
> 4742 /* If this kind of value comes back in memory,
> 4743 decide where in memory it should come back. */
> 4744 if (outmode != VOIDmode)
> 4745 {
> 4746 tfom = lang_hooks.types.type_for_mode (outmode, 0);
> 4747 if (aggregate_value_p (tfom, 0))
> 4748 {
>
> This happen when building SjLj landing pads:
>
> #0 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair<rtx_def*, machine_mode>*)
> () at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> #1 0x0000000000b9b36c in emit_library_call (arg1_mode=<optimized out>,
> arg1=<optimized out>, outmode=E_VOIDmode,
> fn_type=LCT_NORMAL, fun=<optimized out>) at
> /home/uros/gcc-svn/trunk/gcc/rtl.h:4123
> #2 sjlj_emit_function_enter(rtx_code_label*) () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1202
> #3 0x0000000000b9f20a in sjlj_build_landing_pads () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1481
> #4 finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510
>
> Adding -mpreferred-stack-boundary=2 "fixes" compilation.
>
> If you want to experiment, try the following patch:
>
> Index: config/i386/mingw32.h
> ===================================================================
> --- config/i386/mingw32.h (revision 265582)
> +++ config/i386/mingw32.h (working copy)
> @@ -251,6 +251,10 @@
> #undef CHECK_EXECUTE_STACK_ENABLED
> #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
>
> +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> +#define PREFERRED_STACK_BOUNDARY_DEFAULT \
> + (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> +
> /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
> /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
> #if DWARF2_UNWIND_INFO>
> But I don't know the details of MS ABI, so I can't tell if the patch is
> correct.
The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
alignment on function entry is the natural one, but there is in general no
strict requirement for it. So the patch looks fine, but should be commented in
the release notes, as there might be fallout seen caused by it.
