This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch i386]: PR/41315 frame.padding0 isn't treat in all cases of i386
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Kai Tietz <ktietz70 at googlemail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <jh at suse dot cz>
- Date: Wed, 9 Sep 2009 18:21:51 +0200
- Subject: Re: [patch i386]: PR/41315 frame.padding0 isn't treat in all cases of i386
- References: <90baa01f0909090509n266fb727oc120549ca7a6e64e@mail.gmail.com> <4AA7D3E8.2040705@gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Sep 09, 2009 at 06:12:24PM +0200, Uros Bizjak wrote:
> On 09/09/2009 02:09 PM, Kai Tietz wrote:
>> Hello,
>>
>> I reviewed the prologue/epilogue handling of w64 ABI in 386 -as we
>> just had found an failure here in treating stack padding - and I found
>> that the padding0 field was inconsitant handled.
>>
>> ChangeLog
>>
>> 2009-09-09 Kai Tietz<kai.tietz@onevision.com>
>>
>> * config/i386.c (ix86_can_use_return_insn_p): Check for
>> padding0, too.
>> (ix86_expand_prologue): Take frame.padding0 into logic of
>> to_allloc checks.
Too many l's above? Also, isn't it to_allocate? to_alloc is never used in
i386.c.
>> (ix86_expand_epilogue): Likewise.
>>
>> I regression tested patches (one for 4.4, on for trunk) for
>> x86_64-pc-mingw32 and for x86_64-pc-linux64.
>> Ok for apply to head and 4.4 branch?
>>
>
> AFAICS, frame.padding0 is cygwin/mingw thing, so you can approve it
> yourself ;)
Jakub