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.
jeff
