Date: 14 Jan 2004 09:58:25 +0100
Date: Wed, 14 Jan 2004 09:58:25 +0100
From: Andi Kleen <ak@colin2.muc.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Andi Kleen <ak@muc.de>, akpm@osdl.org, jh@suse.cz,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix compilation on gcc 3.4
Message-ID: <20040114085825.GA10916@colin2.muc.de>
References: <20040114083700.GA1820@averell> <20040114084721.GP31589@devserv.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040114084721.GP31589@devserv.devel.redhat.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1066
Lines: 24

On Wed, Jan 14, 2004 at 03:47:22AM -0500, Jakub Jelinek wrote:
> On Wed, Jan 14, 2004 at 09:37:00AM +0100, Andi Kleen wrote:
> > 
> > The upcomming gcc 3.4 has a new inlining algorithm which sometimes
> > fails to inline some "dumb" inlines in the kernel. This sometimes leads
> > to undefined symbols while linking.
> 
> It fails to inline routines with always_inline attribute?
> That sounds like a gcc bug.  always_inline should mean inline always,
> and issue error if for some reason it is impossible.

The problem is that there are some functions that are declared
inline in header files, but there is no body available. When they are
called this ends with an hard error in gcc. I started with fixing
them but eventually gave up because there were so many of them.

In addition you get tons of ugly warnings.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/