| To: | jmorris@xxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: link error building kernel with gcc-3.3 |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Wed, 14 May 2003 22:42:14 -0700 (PDT) |
| Cc: | alex14641@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <Mutt.LNX.4.44.0305151536280.12417-100000@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20030514202941.39519.qmail@xxxxxxxxxxxxxxxxxxxxxxx> <Mutt.LNX.4.44.0305151536280.12417-100000@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: James Morris <jmorris@xxxxxxxxxxxxxxxx> Date: Thu, 15 May 2003 15:38:15 +1000 (EST) I wonder, does this mean that the compiler failed to inline the function? Removing __inline__ is not the correct solution. I already posted what the correct fix is :-) And this is already pushed to 2.5.x Inlining is not guarenteed, and: extern inline ... foo(...) means "inline if you can, I have a compiled-in implementation in some object somewhere" whereas: static inline ... foo(...) means "inline if you can, if there is a case where you cannot emit this as a function into the current module" |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: link error building kernel with gcc-3.3, James Morris |
|---|---|
| Next by Date: | Re: [PATCH] iphase fix., Jeff Garzik |
| Previous by Thread: | Re: link error building kernel with gcc-3.3, James Morris |
| Next by Thread: | Re: link error building kernel with gcc-3.3, Alex Davis |
| Indexes: | [Date] [Thread] [Top] [All Lists] |