[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ktietz at gcc dot gnu.org]

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.