Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Michael Matz wrote:
As "extern inline" is a GNU extension I don't understand this remark.
Sort of.
C99 has the equivalent construct, but spell it differently:
inline foo(int bar) {
...
}
extern foo(int bar);
There is no "static inline" in C99 either; it's just "inline".
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
On Tuesday 06 September 2005 22:55, Terrence Miller wrote: > Andi Kleen wrote: > > I don't think the functionality of having single copies in case > > an out of line version was needed was ever required by the Linux kernel. > > But shouldn't the compiler that compiles Linux be C99 compliant? At least the kernel and some core functionality (glibc) has been traditionally written in GNU C, not ISO C. So no, that is not a design goal. Of course on the other hand GNU C is getting more and more like ISO C with the gcc people dropping extensions over time. Some of the extension use is probably more by mistake, but others (like typeof, inline assembly, statement expressions) are widely and intentionally used and would be quite hard to replace. However people have built the kernel with non gcc compilers, it just needed extensive modifications to either the compiler or the kernel. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Hi, On Tue, 6 Sep 2005, Terrence Miller wrote: > Andi Kleen wrote: > > I don't think the functionality of having single copies in case > > an out of line version was needed was ever required by the Linux kernel. > > But shouldn't the compiler that compiles Linux be C99 compliant? As "extern inline" is a GNU extension I don't understand this remark. The notion of "function marked as inline but in fact wasn't inlined" simply isn't covered by any C(++) standard, and isn't detectable by any C99 compliant program. Hence a compiler understanding this extension could still be c99 compliant (right now I don't know if "extern inline" would be a invalid c99, if it is, then see below). Perhaps you meant "shouldn't linux be compilable by a compiler which only is C99 compliant". If you meant this, then I would say no ;-) Think e.g. inline asms, which a purely (in the sense of providing nothing more) C99 compiler couldn't provide. OTOH gcc with the right options _is_ mostly c99 compliant, so in this sense linux is already compilable by a c99 compliant compiler. Ciao, Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Andi Kleen wrote: > I don't think the functionality of having single copies in case > an out of line version was needed was ever required by the Linux kernel. But shouldn't the compiler that compiles Linux be C99 compliant? > extern inline was used in the kernel a long time ago as a "poor man's > -Winline". Basically the intention was to get an linker error > if the inlining didn't work for some reason because if we say > inline we mean inline. > > But that's long obsolete because the requirements of the C++ "template is > turing complete" people has broken inlining so badly (they want a lot of > inlining, but not too much inlining because otherwise their compile times > explode and the heuristics needed for making some of these pathologic cases > work seems to break a lot of other sane code) that the kernel was forced to > define inline to __attribute__((always_inline)). And with that you get an > error if inlining > fails. > > So the original purpose if extern inline is fulfilled by static inline now. > However extern inline also doesn't hurt, it really makes no difference now. > > -Andi > -- Terrence | Terrence C. Miller | Sun Microsystems | | [EMAIL PROTECTED] | M.S. MPK16-303| | 650-786-9192| 16 Network Circle | | | Menlo Park, CA 94025 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
From: Andi Kleen <[EMAIL PROTECTED]> Date: Tue, 6 Sep 2005 22:23:50 +0200 > I don't think the functionality of having single copies in case > an out of line version was needed was ever required by the Linux kernel. Alpha does, exactly for the kind of case this gcc inlining feature was designed for. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. extern inline was used in the kernel a long time ago as a "poor man's -Winline". Basically the intention was to get an linker error if the inlining didn't work for some reason because if we say inline we mean inline. But that's long obsolete because the requirements of the C++ "template is turing complete" people has broken inlining so badly (they want a lot of inlining, but not too much inlining because otherwise their compile times explode and the heuristics needed for making some of these pathologic cases work seems to break a lot of other sane code) that the kernel was forced to define inline to __attribute__((always_inline)). And with that you get an error if inlining fails. So the original purpose if extern inline is fulfilled by static inline now. However extern inline also doesn't hurt, it really makes no difference now. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Jakub Jelinek wrote:
> On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
>
>>It isn't the same, but "static inline" is the correct variant.
>>
>>"extern inline __attribute__((always_inline))" (which is what
>>"extern inline" is expanded to) doesn't make sense.
>
>
> It does make sense and is different from
> static inline __attribute__((always_inline)).
> Try:
> static inline __attribute__((always_inline)) void foo (void) {}
> void (*fn)(void) = foo;
> vs.
> extern inline __attribute__((always_inline)) void foo (void) {}
> void (*fn)(void) = foo;
> In the former case, GCC will emit the out of line static copy of foo
> if you take its address, in the latter case either you provide foo
> function by other means, or you get linker error.
>
> Jakub
Another standards complient way of dealing with extern inline is
for every module that requires an address generates its own
global copy and the link_once (or COMDAT) facility is used to eliminate
all but one.
--
Terrence
| Terrence C. Miller | Sun Microsystems |
| [EMAIL PROTECTED] | M.S. MPK16-303|
| 650-786-9192| 16 Network Circle |
| | Menlo Park, CA 94025 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Jakub Jelinek wrote:
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
It isn't the same, but static inline is the correct variant.
extern inline __attribute__((always_inline)) (which is what
extern inline is expanded to) doesn't make sense.
It does make sense and is different from
static inline __attribute__((always_inline)).
Try:
static inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
vs.
extern inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
In the former case, GCC will emit the out of line static copy of foo
if you take its address, in the latter case either you provide foo
function by other means, or you get linker error.
Jakub
Another standards complient way of dealing with extern inline is
for every module that requires an address generates its own
global copy and the link_once (or COMDAT) facility is used to eliminate
all but one.
--
Terrence
| Terrence C. Miller | Sun Microsystems |
| [EMAIL PROTECTED] | M.S. MPK16-303|
| 650-786-9192| 16 Network Circle |
| | Menlo Park, CA 94025 |
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. extern inline was used in the kernel a long time ago as a poor man's -Winline. Basically the intention was to get an linker error if the inlining didn't work for some reason because if we say inline we mean inline. But that's long obsolete because the requirements of the C++ template is turing complete people has broken inlining so badly (they want a lot of inlining, but not too much inlining because otherwise their compile times explode and the heuristics needed for making some of these pathologic cases work seems to break a lot of other sane code) that the kernel was forced to define inline to __attribute__((always_inline)). And with that you get an error if inlining fails. So the original purpose if extern inline is fulfilled by static inline now. However extern inline also doesn't hurt, it really makes no difference now. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 22:23:50 +0200 I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. Alpha does, exactly for the kind of case this gcc inlining feature was designed for. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Andi Kleen wrote: I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. But shouldn't the compiler that compiles Linux be C99 compliant? extern inline was used in the kernel a long time ago as a poor man's -Winline. Basically the intention was to get an linker error if the inlining didn't work for some reason because if we say inline we mean inline. But that's long obsolete because the requirements of the C++ template is turing complete people has broken inlining so badly (they want a lot of inlining, but not too much inlining because otherwise their compile times explode and the heuristics needed for making some of these pathologic cases work seems to break a lot of other sane code) that the kernel was forced to define inline to __attribute__((always_inline)). And with that you get an error if inlining fails. So the original purpose if extern inline is fulfilled by static inline now. However extern inline also doesn't hurt, it really makes no difference now. -Andi -- Terrence | Terrence C. Miller | Sun Microsystems | | [EMAIL PROTECTED] | M.S. MPK16-303| | 650-786-9192| 16 Network Circle | | | Menlo Park, CA 94025 | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Hi, On Tue, 6 Sep 2005, Terrence Miller wrote: Andi Kleen wrote: I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. But shouldn't the compiler that compiles Linux be C99 compliant? As extern inline is a GNU extension I don't understand this remark. The notion of function marked as inline but in fact wasn't inlined simply isn't covered by any C(++) standard, and isn't detectable by any C99 compliant program. Hence a compiler understanding this extension could still be c99 compliant (right now I don't know if extern inline would be a invalid c99, if it is, then see below). Perhaps you meant shouldn't linux be compilable by a compiler which only is C99 compliant. If you meant this, then I would say no ;-) Think e.g. inline asms, which a purely (in the sense of providing nothing more) C99 compiler couldn't provide. OTOH gcc with the right options _is_ mostly c99 compliant, so in this sense linux is already compilable by a c99 compliant compiler. Ciao, Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
On Tuesday 06 September 2005 22:55, Terrence Miller wrote: Andi Kleen wrote: I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. But shouldn't the compiler that compiles Linux be C99 compliant? At least the kernel and some core functionality (glibc) has been traditionally written in GNU C, not ISO C. So no, that is not a design goal. Of course on the other hand GNU C is getting more and more like ISO C with the gcc people dropping extensions over time. Some of the extension use is probably more by mistake, but others (like typeof, inline assembly, statement expressions) are widely and intentionally used and would be quite hard to replace. However people have built the kernel with non gcc compilers, it just needed extensive modifications to either the compiler or the kernel. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Michael Matz wrote:
As extern inline is a GNU extension I don't understand this remark.
Sort of.
C99 has the equivalent construct, but spell it differently:
inline foo(int bar) {
...
}
extern foo(int bar);
There is no static inline in C99 either; it's just inline.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Followup to: <[EMAIL PROTECTED]>
By author:Adrian Bunk <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
> > On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> > > It isn't the same, but "static inline" is the correct variant.
> > >
> > > "extern inline __attribute__((always_inline))" (which is what
> > > "extern inline" is expanded to) doesn't make sense.
> >
> > It does make sense and is different from
> > static inline __attribute__((always_inline)).
> > Try:
> > static inline __attribute__((always_inline)) void foo (void) {}
> > void (*fn)(void) = foo;
> > vs.
> > extern inline __attribute__((always_inline)) void foo (void) {}
> > void (*fn)(void) = foo;
> > In the former case, GCC will emit the out of line static copy of foo
> > if you take its address, in the latter case either you provide foo
> > function by other means, or you get linker error.
>
> And we need the former case because in the kernel we do not have
> out-of-line variants of the inline functions.
>
UNLESS the function is broken if out-of-lined. If the function cannot
be safely out-of-lined, extern inline MUST be used.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
On Friday 02 September 2005 22:31, Adrian Bunk wrote: > "extern inline" doesn't make much sense. > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks applied (with a better description) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
> On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> > It isn't the same, but "static inline" is the correct variant.
> >
> > "extern inline __attribute__((always_inline))" (which is what
> > "extern inline" is expanded to) doesn't make sense.
>
> It does make sense and is different from
> static inline __attribute__((always_inline)).
> Try:
> static inline __attribute__((always_inline)) void foo (void) {}
> void (*fn)(void) = foo;
> vs.
> extern inline __attribute__((always_inline)) void foo (void) {}
> void (*fn)(void) = foo;
> In the former case, GCC will emit the out of line static copy of foo
> if you take its address, in the latter case either you provide foo
> function by other means, or you get linker error.
And we need the former case because in the kernel we do not have
out-of-line variants of the inline functions.
> Jakub
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> It isn't the same, but "static inline" is the correct variant.
>
> "extern inline __attribute__((always_inline))" (which is what
> "extern inline" is expanded to) doesn't make sense.
It does make sense and is different from
static inline __attribute__((always_inline)).
Try:
static inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
vs.
extern inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
In the former case, GCC will emit the out of line static copy of foo
if you take its address, in the latter case either you provide foo
function by other means, or you get linker error.
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
On Mon, Sep 05, 2005 at 10:52:47AM +0200, Michael Matz wrote: > Hi, > > On Fri, 2 Sep 2005, Adrian Bunk wrote: > > > "extern inline" doesn't make much sense. > > It does. It's a GCC extension which says "never ever emit an out-of-line > version of this function, not even if its address is taken", i.e. it's > implicitely assumed, that if there is a need for such out-of-line variant, > then it is provided by some other mean (for instance by defining it > without inline markers in some .o file). Usually there won't be such need So you agree with my statement that it doesn't make sense because there are no out-of-line variants? > as all instances are inlined, in which case the out-of-line version would > be dead bloat, which you can't get rid of without this extension. And if > some calls are not inlined then this extension serves as a poor mans > check, because a link error will result. In the kernel (with gcc >= 3.1), _every_ inline is forced to always_inline resulting in gcc aborting with an error if it can't inline the function. Therefore any such out-of-line version if it existed would be dead bloat. > All in all, it does make sense, and no it's not the same as a "static > inline", not even if forced always_inline. It isn't the same, but "static inline" is the correct variant. "extern inline __attribute__((always_inline))" (which is what "extern inline" is expanded to) doesn't make sense. > Ciao, > Michael. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
Hi, On Fri, 2 Sep 2005, Adrian Bunk wrote: > "extern inline" doesn't make much sense. It does. It's a GCC extension which says "never ever emit an out-of-line version of this function, not even if its address is taken", i.e. it's implicitely assumed, that if there is a need for such out-of-line variant, then it is provided by some other mean (for instance by defining it without inline markers in some .o file). Usually there won't be such need as all instances are inlined, in which case the out-of-line version would be dead bloat, which you can't get rid of without this extension. And if some calls are not inlined then this extension serves as a poor mans check, because a link error will result. All in all, it does make sense, and no it's not the same as a "static inline", not even if forced always_inline. Ciao, Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Hi, On Fri, 2 Sep 2005, Adrian Bunk wrote: extern inline doesn't make much sense. It does. It's a GCC extension which says never ever emit an out-of-line version of this function, not even if its address is taken, i.e. it's implicitely assumed, that if there is a need for such out-of-line variant, then it is provided by some other mean (for instance by defining it without inline markers in some .o file). Usually there won't be such need as all instances are inlined, in which case the out-of-line version would be dead bloat, which you can't get rid of without this extension. And if some calls are not inlined then this extension serves as a poor mans check, because a link error will result. All in all, it does make sense, and no it's not the same as a static inline, not even if forced always_inline. Ciao, Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
On Mon, Sep 05, 2005 at 10:52:47AM +0200, Michael Matz wrote: Hi, On Fri, 2 Sep 2005, Adrian Bunk wrote: extern inline doesn't make much sense. It does. It's a GCC extension which says never ever emit an out-of-line version of this function, not even if its address is taken, i.e. it's implicitely assumed, that if there is a need for such out-of-line variant, then it is provided by some other mean (for instance by defining it without inline markers in some .o file). Usually there won't be such need So you agree with my statement that it doesn't make sense because there are no out-of-line variants? as all instances are inlined, in which case the out-of-line version would be dead bloat, which you can't get rid of without this extension. And if some calls are not inlined then this extension serves as a poor mans check, because a link error will result. In the kernel (with gcc = 3.1), _every_ inline is forced to always_inline resulting in gcc aborting with an error if it can't inline the function. Therefore any such out-of-line version if it existed would be dead bloat. All in all, it does make sense, and no it's not the same as a static inline, not even if forced always_inline. It isn't the same, but static inline is the correct variant. extern inline __attribute__((always_inline)) (which is what extern inline is expanded to) doesn't make sense. Ciao, Michael. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
It isn't the same, but static inline is the correct variant.
extern inline __attribute__((always_inline)) (which is what
extern inline is expanded to) doesn't make sense.
It does make sense and is different from
static inline __attribute__((always_inline)).
Try:
static inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
vs.
extern inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
In the former case, GCC will emit the out of line static copy of foo
if you take its address, in the latter case either you provide foo
function by other means, or you get linker error.
Jakub
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
It isn't the same, but static inline is the correct variant.
extern inline __attribute__((always_inline)) (which is what
extern inline is expanded to) doesn't make sense.
It does make sense and is different from
static inline __attribute__((always_inline)).
Try:
static inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
vs.
extern inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
In the former case, GCC will emit the out of line static copy of foo
if you take its address, in the latter case either you provide foo
function by other means, or you get linker error.
And we need the former case because in the kernel we do not have
out-of-line variants of the inline functions.
Jakub
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
On Friday 02 September 2005 22:31, Adrian Bunk wrote: extern inline doesn't make much sense. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Thanks applied (with a better description) -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
Followup to: [EMAIL PROTECTED]
By author:Adrian Bunk [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
It isn't the same, but static inline is the correct variant.
extern inline __attribute__((always_inline)) (which is what
extern inline is expanded to) doesn't make sense.
It does make sense and is different from
static inline __attribute__((always_inline)).
Try:
static inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
vs.
extern inline __attribute__((always_inline)) void foo (void) {}
void (*fn)(void) = foo;
In the former case, GCC will emit the out of line static copy of foo
if you take its address, in the latter case either you provide foo
function by other means, or you get linker error.
And we need the former case because in the kernel we do not have
out-of-line variants of the inline functions.
UNLESS the function is broken if out-of-lined. If the function cannot
be safely out-of-lined, extern inline MUST be used.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
