Messages in this thread Patch in this message | | | Date | Tue, 1 May 2007 23:41:34 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [patch 01/10] compiler: define __attribute_unused__ |
| |
On Wed, 2 May 2007, Rusty Russell wrote:
> OTOH, your point about "__unneeded" is well taken. "__needed" and > "__optional" perhaps? But their feature is *exactly* that the don't > look like the gcc attributes, hence avoid their semantic screwage. >
Hmm, __optional doesn't sound appropriate either. Since this is going to be defined to be __attribute__ ((unused)), it can apply to both functions and variables. It should be applied to a function if it truly is unreferenced within the tree (and there are several examples of this current HEAD) and we don't want to use __needed because it still emits the function code even though it suppresses the warning. So saying a function that has no callers is "__optional" makes no sense since its code isn't going to be emitted in gcc >=3.4.
What's your opinion of my __needed and __maybe_unused idea such as the following?
compiler: define __maybe_unused
Define __maybe_unused to apply to both functions or variables as __attribute__((unused)). This will not emit a compile-time warning when a function or variable is declared but unreferenced.
We eventually want to change the name of __attribute_used__ to __used.
Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/compiler-gcc.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -37,3 +37,4 @@ #define noinline __attribute__((noinline)) #define __attribute_pure__ __attribute__((pure)) #define __attribute_const__ __attribute__((__const__)) +#define __maybe_unused __attribute__((unused)) - 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/
| |