To: linux-kernel@vger.kernel.org
Subject: macro in linux/compiler.h pollutes gcc __attribute__ namespace
From: Timmy Douglas <timmy+lkml@cc.gatech.edu>
Date: Wed, 04 May 2005 13:35:08 -0400
Message-ID: <87vf5y99o3.fsf@mail.gatech.edu>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1135
Lines: 41

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

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