Re: [PATCH v2, middle end]: Fix PR58372, internal compiler error: ix86_compute_frame_layout

[Uros Bizjak <ubizjak at gmail dot com>]

On Sun, Nov 4, 2018 at 6:59 PM Jeff Law <law@redhat.com> wrote:
>
> On 11/1/18 10:18 AM, Uros Bizjak wrote:
> > Hello!
> >
> > v2 of the patch hits the real problem: in pass_expand::execute
> > finish_eh_generation is called after expand_stack_alignment is called.
> > Construction of SjLj landing pads calls emit_library_call, which can
> > change crtl->preferred_stack_boundary value after all dependant
> > variables are already calculated by expand_stack_alignment.
> >
> > The solution is to move the call to finish_eh_generation in front of
> > the call to expand_stack_alignment.
> >
> > 2018-11-01  Uros Bizjak  <ubizjak@gmail.com>
> >
> >     PR middle-end/58372
> >     * cfgexpand.c (pass_expand::execute): Move the call to
> >     finish_eh_generation in front of the call to expand_stack_alignment.
> >
> > testsuite/ChangeLog:
> >
> > 2018-11-01  Uros Bizjak  <ubizjak@gmail.com>
> >
> >     PR middle-end/58372
> >     * g++.target/i386/pr58372.C: New test.
> >
> > Patch was bootstrapped and regression tested on x86_64-linux-gnu
> > {,-m32}, all default languages plus go. Additionally, the testcase
> > from PR (and a couple of similar ones) were compiled for
> > i686-w64-mingw32 target with various combinations of
> > -mpreferred-stack-boundary= -mincoming-stack-boundary= -mforce-drap
> > and -m{no-}accumulate-outgoing-args.
> >
> > OK for mainline and release branches?
> >
> > Uros.
> >
> OK, but please add a comment indicating why the new sequencing is needed
> in the code.

Thanks, committed with the following comment:

  /* Call expand_stack_alignment after finishing all
     updates to crtl->preferred_stack_boundary.  */
  expand_stack_alignment ();

I'll backport the patch to release branches after a week without
problems in the mainline.

Uros.