lkml.org 
[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: macro in linux/compiler.h pollutes gcc __attribute__ namespace
Timmy Douglas wrote:
> (I'm not subscribed so please CC me replies that you want me to reply
> to.)
>
> Recently I've found a problem with emacs where gcc optimizes a
> function to be inline where it shouldn't be. The emacs developers use
> a macro like this:
>
> #define NO_INLINE __attribute__((noinline))
>
> that would normally work fine but when we compile the file with
> NO_INLINE, the -E output looks like:
>
> static void __attribute__(())
> x_error_quitter (display, error)
> Display *display;
> XErrorEvent *error;
> {
> char buf[256], buf1[356];
>
> ...etc
>
>
> I've realized that this file includes linux/compiler.h which does:
>
>
> 139
> 140 #ifndef noinline
> 141 #define noinline
> 142 #endif
> 143
>
> which causes __atribute__((noinline)) to change into
> __attribute__(()). I'm not sure how linux developers keep a function
> from getting inlined, but I'm hoping someone will consider removing or
> changing this macro.

The right question to be asking is why is emacs including kernel headers?

--
Brian Gerst
-
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/

\
 
 \ /
  Last update: 2005-05-04 19:51    [W:0.062 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site