On Sun, Nov 4, 2018 at 6:59 PM Jeff Law <l...@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 <ubiz...@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 <ubiz...@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.
