macro in linux/compiler.h pollutes gcc __attribute__ namespace

macro in linux/compiler.h pollutes gcc __attribute__ namespace

[Timmy Douglas]

(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.

Re: macro in linux/compiler.h pollutes gcc __attribute__ namespace

[Brian Gerst]

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

Re: macro in linux/compiler.h pollutes gcc __attribute__ namespace

[Timmy Douglas]

Brian Gerst <bgerst@didntduck.org> writes:

> 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:
>>[snip]
>> I've realized that this file includes linux/compiler.h which does:
>>    139
>>    140  #ifndef noinline
>>    141  #define noinline
>>    142  #endif
>>    143
>>[snip]
>
> The right question to be asking is why is emacs including kernel headers?

I'm guessing it goes sort of like this:

signal.h -> bits/sigcontext.h -> asm/sigcontext.h -> linux/compiler.h

Re: macro in linux/compiler.h pollutes gcc __attribute__ namespace

[Kyle Moffett]

On May 4, 2005, at 14:10:21, Timmy Douglas wrote:
> I'm guessing it goes sort of like this:
>
> signal.h -> bits/sigcontext.h -> asm/sigcontext.h -> linux/compiler.h

Installing headers directly from the kernel has been deprecated for
quite a while.  Please look for the "linux-kernel-headers" package in
whatever your package management system is.  It has a set of cleaned
headers.  IIRC, there were some proposals a while back for how to fix
this and make a set of headers useable from userspace, but nothing
substantial ever got done.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

Re: macro in linux/compiler.h pollutes gcc __attribute__ namespace

[Timmy Douglas]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> On May 4, 2005, at 14:10:21, Timmy Douglas wrote:
>> I'm guessing it goes sort of like this:
>>
>> signal.h -> bits/sigcontext.h -> asm/sigcontext.h -> linux/compiler.h
>
> Installing headers directly from the kernel has been deprecated for
> quite a while.  Please look for the "linux-kernel-headers" package
> in whatever your package management system is.  It has a set of
> cleaned headers.  IIRC, there were some proposals a while back for
> how to fix this and make a set of headers useable from userspace,
> but nothing substantial ever got done.

Thanks for the input. It seems this is a gentoo bug then because it
leaves this #define in their version of the source (even though it
removes some other things). I don't see this problem on a debian box I
have though. Too bad this wasn't standardized on.

Thanks again.