This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFT PATCH, i386]: Fix PR87928, ICE in ix86_compute_frame_layout
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: iain at sandoe dot co dot uk
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Kai Tietz <ktietz70 at gmail dot com>
- Date: Sun, 11 Nov 2018 20:34:18 +0100
- Subject: Re: [RFT PATCH, i386]: Fix PR87928, ICE in ix86_compute_frame_layout
- References: <CAFULd4ZWvawXdSSupHC5ih=NRr+dsy_GEF_eYLbJGVE2L6qTHw@mail.gmail.com> <1BB7C3AD-0E2F-437D-BA76-B1D131E143BD@sandoe.co.uk>
On Fri, Nov 9, 2018 at 7:37 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
> Bootstrap succeeds and the new test passes for Darwin.
>
> This does not alter that Darwin has breakage in this area (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444)
> see : https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00884.html and HJ’s reply.
You can't use crtl->is_leaf in ix86_update_stack_boundary, since that
function gets called from cfgexpand, while crtl->is_leaf is set only
in IRA pass.
I *think* the fix should be along the lines of TARGET_64BIT_MS_ABI
fixup in ix86_compute_frame_layout (BTW: the existing fixup is strange
by itself, since TARGET_64BIT_MS_ABI declares STACK_BOUNDARY to 128,
and I can't see how leaf functions with crtl->preferred_stack_boundary
< 128 survive "gcc_assert (preferred_alignment >= STACK_BOUNDARY /
BITS_PER_UNIT);" a couple of lines below).
So, I think that fixup you proposed in the patch is in the right
direction. What happens if you add TARGET_MACHO to the existing fixup?
Uros.