Messages in this thread | | | Date | Thu, 26 Apr 2012 15:29:09 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 1/4] compiler.h: introduce unused_expression() macro |
| |
On Wed, 25 Apr 2012 15:26:23 +0400 Konstantin Khlebnikov <khlebnikov@openvz.org> wrote:
> Sometimes we want to check some expressions correctness in compile-time without > generating extra code. "(void)(e)" does not work if expression has side-effects. > This patch introduces macro unused_expression() which helps in this situation. > > Cast to "long" required because sizeof does not work for bit-fields. > > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > --- > include/linux/compiler.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 923d093..46fbda3 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -310,4 +310,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); > */ > #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) > > +#define unused_expression(e) ((void)(sizeof((__force long)(e)))) > +
hm, maybe.
Thing is, if anyone ever has an expression-with-side-effects within conditionally-compiled code then they probably have a bug, don't they? I mean, as an extreme example
VM_BUG_ON(do_something_important());
is a nice little hand-grenade. Your patch will cause that (bad) code to newly fail at runtime, but our coverage testing is so awful that it would take a long time for the bug to be discovered.
It would be nice if we could cause the build to warn or outright fail if the unused_expression() argument would have caused any code generation. But I can't suggest how to do that.
Your changelogs assert that gcc is emitting code for these expressions, but details are not presented. Please give examples - where is this code generation coming from, what is causing it?
Bottom line: are these patches a workaround for gcc inadequacies, or are they a bandaid covering up poor kernel code?
| |