On Wed, 25 Apr 2012 15:26:23 +0400 Konstantin Khlebnikov <khlebnikov@xxxxxxxxxx> 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@xxxxxxxxxx> > --- > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
