This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: Kurt Garloff <garloff at suse dot de>, gcc at gcc dot gnu dot org, dalej at apple dot com
- Date: Wed, 05 Mar 2003 14:05:14 -0800
- Subject: Re: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)
- References: <20030302160629.GV16943@nbkurt> <jm1y1pwn16.fsf@desire.geoffk.org><20030304012745.GH3017@nbkurt> <20030305192315.GO11208@E2.suse.de><jmzno9trl8.fsf@desire.geoffk.org>
Geoff Keating <geoffk at geoffk dot org> writes:
> Kurt Garloff <garloff at suse dot de> writes:
>
>> 1. In gcc-3_3-branch, the first patch (as attached in the mail from
>> saturday) should IMHO be applied as it fixes PR/8387. Before 3.3.0
>> release if it's further delayed, otherwise afterwards.
>> Note that we've seen a kernel compile failure on x86-64 with 3.3
>> snapshots which was due to a a function not being inlined because
>> it was considered too large and the increased -finline-limit passed by
>> the Makefile was not effective.
>> So if kernel compilation is a release criterium for 3.3, the fix
>> should go in in any case.
>
> The 3.3 release can't happen right now, because (among other things)
> there's a codegen regression on Darwin. This patch is reasonably safe
> and fairly important (especially if it affects linux kernel
> compilation), so I think it should go in; Dale volunteered to do the
> actual commit.
Agree - in fact I think both patches (the one that directly addresses
the PR, and the one that further refines the heuristics, making a
distinction between functions explicitly marked inlines and otherwise)
should be applied to the branch.
zw