[PATCH 0/10] Cleanup & new features for compiler*.h and bug.h

[PATCH 0/10] Cleanup & new features for compiler*.h and bug.h

[Daniel Santos]

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve the
manageability of of compiler features at various versions (when they are
broken, etc.), and to add some needed features to bug.h (again, that are
compiler-version-dependent).

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701)
o Reorder all features based upon the version introduced (readability)
o Change all version checks to use GCC_VERSION
o Remove redundant __linktime_error
o Introduce __flatten function attribute

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Introduce BUILD_BUG_ON_NON_CONST(expr) macro, which simply wraps
  __builtin_constant_p and BUILD_BUG_ON
o Documented (in BUILD_BUG_ON_NON_CONST doc-comments) the extensive
  discrepancies in the behavior of __builtin_constant_p throughout versions of
  gcc.
o Introduce BUILD_BUG_ON_NON_CONST42 macro for compile-time-constant checks
  that are doomed to fail in older versions of gcc.

[PATCH 1/10] compiler-gcc4.h: correct verion check for __compiletime_error

[Daniel Santos]

NOTE: this is has already been comitted to -mm

__attribute__((error(msg))) was introduced in gcc 4.3 (not 4.4) and as I
was unable to find any gcc bugs pertaining to it, I'm presuming that it
has functioned as advertised since 4.3.0.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/compiler-gcc4.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 997fd8a..8721704 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -59,7 +59,7 @@
 #if __GNUC_MINOR__ > 0
 #define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
-#if __GNUC_MINOR__ >= 4 && !defined(__CHECKER__)
+#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
 #define __compiletime_warning(message) __attribute__((warning(message)))
 #define __compiletime_error(message) __attribute__((error(message)))
 #endif
-- 
1.7.3.4

[PATCH 2/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[Daniel Santos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8721704..4506d65 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Daniel Santos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Daniel Santos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 4506d65..b44307d 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 //#  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40102
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros

[Daniel Santos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 2 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index b44307d..ad610f2 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index f430e41..fd455aa 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -297,9 +297,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Daniel Santos]

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..298a916 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
-- 
1.7.3.4

[PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Daniel Santos]

For gcc 4.1 & later, expands to __attribute__((flatten)) which forces
the compiler to inline everything it can into the function.  This is
useful in combination with noinline when you want to control the depth
of inlining, or create a single function where inline expansions will
occur. (see
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bflatten_007d-function-attribute-2512)

Normally, it's best to leave this type of thing up to the compiler.
However, the generic rbtree code uses inline functions just to be able
to inject compile-time constant data that specifies how the caller wants
the function to behave (via struct rb_relationship).  This data can be
thought of as the template parameters of a C++ templatized function.
Since some of these functions, once expanded, become quite large, gcc
sometimes decides not to perform some important inlining, in one case,
even generating a few bytes more code by not doing so. (Note: I have not
eliminated the possibility that this was an optimization bug, but the
flatten attribute fixes it in either case.)

Combining __flatten and noinline insures that important optimizations
occur in these cases and that the inline expansion occurs in exactly one
place, thus not leading to unnecissary bloat. However, it also can
eliminate some opportunities for optimization should gcc otherwise
decide the function its self is a good candidate for inlining.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/compiler-gcc4.h |    7 ++++++-
 include/linux/compiler.h      |    4 ++++
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index ad610f2..5a0897e 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -15,7 +15,12 @@
 
 #if GCC_VERSION >= 40102
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
+
+/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/
+# if GCC_VERSION != 40600
+#  define __flatten __attribute__((flatten))
+# endif
+#endif /* GCC_VERSION >= 40102 */
 
 #if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index fd455aa..268aeb6 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -244,6 +244,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #define __always_inline inline
 #endif
 
+#ifndef __flatten
+#define __flatten
+#endif
+
 #endif /* __KERNEL__ */
 
 /*
-- 
1.7.3.4

[PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 298a916..c70b833 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -42,24 +42,28 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
  * The implementation uses gcc's reluctance to create a negative array, but
  * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * to inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error pre-gcc-4.4) and then call an undefined
+ * function with the error attribute (should always creates an error 4.3+).  If
+ * for some reason, neither creates a compile-time error, we'll still have a
+ * link-time error, which is harder to track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		if (condition)						\
+			__build_bug_on_failed();			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH 9/10] bug.h: Add BUILD_BUG_ON_NON_CONST macro

[Daniel Santos]

A very common use of __builtin_constant_p is to make sure that a certain
value is a compile time constant and generate a build-time error if it
is not.  However, __builtin_constant_p is broken in a variety of ways in
various situations (on various versions of gcc) and never returns one in
an unoptimized build. This macro provide a mechanism to perform these
build-time checks, but not break unoptimized builds (or modules being
build with -O0), of which there probably aren't many people that care
anyway.

This patch documents all of the relevant quirks I could find in the
"Gory Details" section of the doc-comments.  For almost all cases,
BUILD_BUG_ON_NON_CONST() should never fail on a primitive, non-pointer
type variable declared const.  A subsequent patch provides a separate
macro for performing tests which are known to be broken in older
compilers (pretty much, using __builtin_constant_p on arrays, pointers &
structs as well as testing those values).

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index c70b833..e30f600 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -81,6 +81,54 @@ struct pt_regs;
 		__build_bug_failed();				\
 	} while (0)
 
+/**
+ * BUILD_BUG_ON_NON_CONST - break compile if expression cannot be determined
+ *                          to be a compile-time constant.
+ * @exp: value to test for compile-time constness
+ *
+ * __builtin_constant_p() is a work in progress and is broken in various ways
+ * on various versions of gcc and optimization levels. It can fail, even when
+ * gcc otherwise determines that the expression is compile-time constant when
+ * performing actual optimizations and thus, compile out the value anyway. Do
+ * not use this macro for struct members or dereferenced pointers and arrays,
+ * as these are broken in many versions of gcc -- use BUILD_BUG_ON_NON_CONST42
+ * or another gcc-version-checked macro instead.
+ *
+ * As long as you are passing a variable declared const (and not modified),
+ * this macro should never fail (except for floats).  For information on gcc's
+ * behavior in other cases, see below.
+ *
+ * Gory Details:
+ *
+ * Normal primitive variables
+ * - global non-static non-const values are never compile-time constants (but
+ *   you should already know that)
+ * - all const values (global/local, non/static) should never fail this test
+ *   (3.4+) with one exception (below)
+ * - floats (which we wont use anyway) are broken in various ways until 4.2
+ *   (-O1 broken until 4.4)
+ * - local static non-const broken until 4.2 (-O1 broken until 4.3)
+ * - local non-static non-const broken until 4.0
+ *
+ * Dereferencing pointers & arrays
+ * - all static const derefs broken until 4.4 (except arrays at -O2 or better,
+ *   which are fixed in 4.2)
+ * - global non-static const pointer derefs always fail (<=4.7)
+ * - local non-static const derefs broken until 4.3, except for array derefs
+ *   to a zero value, which works from 4.0+
+ * - local static non-const pointers always fail (<=4.7)
+ * - local static non-const arrays broken until 4.4
+ * - local non-static non-const arrays broken until 4.0 (unless zero deref,
+ *   works in 3.4+)
+
+ */
+#ifdef __OPTIMIZE__
+#define BUILD_BUG_ON_NON_CONST(exp) \
+	BUILD_BUG_ON(!__builtin_constant_p(exp))
+#else
+#define BUILD_BUG_ON_NON_CONST(exp)
+#endif
+
 #endif	/* __CHECKER__ */
 
 #ifdef CONFIG_GENERIC_BUG
-- 
1.7.3.4

[PATCH 10/10] bug.h: Add gcc 4.2+ versions of BUILD_BUG_ON_* macros

[Daniel Santos]

BUILD_BUG_ON42(arg)
BUILD_BUG_ON_CONST42(arg)

Prior to gcc 4.2, the optimizer was unable to determine that many
constant values stored in structs were indeed compile-time constants and
optimize them out.  Sometimes, it will find an intergral value to be a
compile-time constant, but fail to perform a bit-wise AND at
compile-time.  These two macros provide a mechanism to perform these
build-time checks, but not break on older compilers where we already
know they can't be checked at compile time.

For specific details, consult the doc comments for BUILD_BUG_ON_CONST.
These macros are used in the generic rbtree code.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index e30f600..d14c23c 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -129,6 +130,41 @@ struct pt_regs;
 #define BUILD_BUG_ON_NON_CONST(exp)
 #endif
 
+
+#if GCC_VERSION >= 40200
+/**
+ * BUILD_BUG_ON_NON_CONST42 - break compile if expression cannot be determined
+ *                            to be a compile-time constant (disabled prior to
+ *                            gcc 4.2)
+ * @exp: value to test for compile-time constness
+ *
+ * Use this macro instead of BUILD_BUG_ON_NON_CONST when testing struct
+ * members or dereferenced arrays and pointers.  Note that the version checks
+ * for this macro are not perfect.  BUILD_BUG_ON_NON_CONST42 expands to nothing
+ * prior to gcc-4.2, after which it is the same as BUILD_BUG_ON_NON_CONST.
+ * However, there are still many checks that will break with this macro (see
+ * the Gory Details section of BUILD_BUG_ON_NON_CONST for more info).
+ *
+ * See also BUILD_BUG_ON_NON_CONST()
+ */
+# define BUILD_BUG_ON_NON_CONST42(exp) BUILD_BUG_ON_NON_CONST(exp)
+
+/**
+ * BUILD_BUG_ON42 - break compile if expression cannot be determined
+ *                   (disabled prior to gcc 4.2)
+ *
+ * This gcc-version check is necessary due to breakages in testing struct
+ * members prior to gcc 4.2.
+ *
+ * See also BUILD_BUG_ON()
+ */
+# define BUILD_BUG_ON42(arg) BUILD_BUG_ON(arg)
+#else
+# define BUILD_BUG_ON_NON_CONST42(exp)
+# define BUILD_BUG_ON42(arg)
+#endif /* GCC_VERSION >= 40200 */
+
+
 #endif	/* __CHECKER__ */
 
 #ifdef CONFIG_GENERIC_BUG
-- 
1.7.3.4

Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Josh Triplett]

On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote:
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -13,11 +13,11 @@
>  #define __must_check 		__attribute__((warn_unused_result))
>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
>  
> -#if __GNUC_MINOR__ > 0
> +#if GCC_VERSION >= 40102
>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>  #endif

You've changed the semantics of this one; if literally translated, this
should have become #if GCC_VERSION >= 40100.  If you intended to change
that, could you please document why?  And in any case, could you make
that semantic change in a separate commit from the switch to
GCC_VERSION?

- Josh Triplett

Re: [PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros

[Josh Triplett]

On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote:
> __linktime_error() does the same thing as __compiletime_error() and is
> only used in bug.h.  Since the macro defines a function attribute that
> will cause a failure at compile-time (not link-time), it makes more
> sense to keep __compiletime_error(), which is also neatly mated with
> __compiletime_warning().
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Why not change bug.h in the same commit?  Or alternatively, why not
change it first?  Getting rid of __linktime_error *before* changing its
use in bug.h to __compiletime_error seems wrong.

- Josh Triplett

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Josh Triplett]

On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index aaac4bb..298a916 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
>  #define BUILD_BUG()						\
>  	do {							\
>  		extern void __build_bug_failed(void)		\
> -			__linktime_error("BUILD_BUG failed");	\
> +			__compiletime_error("BUILD_BUG failed");\
>  		__build_bug_failed();				\
>  	} while (0)

This change should either occur as part of patch 5 or before patch 5,
not after.

- Josh Triplett

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Josh Triplett]

On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote:
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -15,7 +15,12 @@
>  
>  #if GCC_VERSION >= 40102
>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> +
> +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/
> +# if GCC_VERSION != 40600
> +#  define __flatten __attribute__((flatten))
> +# endif
> +#endif /* GCC_VERSION >= 40102 */

Same comment as before: why 40102 rather than 40100?

- Josh Triplett

Re: [Bulk] Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Daniel Santos]

On 09/28/2012 07:20 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote:
>> --- a/include/linux/compiler-gcc4.h
>> +++ b/include/linux/compiler-gcc4.h
>> @@ -13,11 +13,11 @@
>>  #define __must_check 		__attribute__((warn_unused_result))
>>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
>>  
>> -#if __GNUC_MINOR__ > 0
>> +#if GCC_VERSION >= 40102
>>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>>  #endif
> You've changed the semantics of this one; if literally translated, this
> should have become #if GCC_VERSION >= 40100.  If you intended to change
> that, could you please document why?  And in any case, could you make
> that semantic change in a separate commit from the switch to
> GCC_VERSION?
hmm, it looks like somebody commented out the #error that would normally
prevent that test from ever occurring on 4.1.0 or 4.1.1.
When I had written this patch, it wasn't commented out and I had assumed
that it was obvious from the context.
>  /* GCC 4.1.[01] miscompiles __weak */
>  #ifdef __KERNEL__
> -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> +# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
>  //#  error Your version of gcc miscompiles the __weak directive
>  # endif
>  #endif
> @@ -13,11 +13,11 @@
>  #define __must_check 		__attribute__((warn_unused_result))
>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
>  
> -#if __GNUC_MINOR__ > 0
> +#if GCC_VERSION >= 40102
>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>  #endif
I would say that commenting this out is bad if __weak is miscompiled. 
If we don't want to break the build, should we at least be defining
__weak to something else?

Daniel

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Josh Triplett]

On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will.  This patch modifies
> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> function attribute so that you don't have to build the entire kernel to
> discover that you have a problem, and then enjoy trying to track it down
> from a link-time error.

Rather than doing both, and potentially producing two errors for the
same issue, how about using __compiletime_error only, and only using the
negative-sized array when __compiletime_error has no useful definition?

For instance, in compiler.h, when defining __compiletime_error as an
empty macro in the fallback case, you could define a
__compiletime_error_fallback() macro that declares a negative-sized
array; you could then define __compiletime_error_fallback() as an empty
macro when it doesn't exist.

- Josh Triplett

Re: [Bulk] Re: [PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros

[Daniel Santos]

On 09/28/2012 07:23 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote:
>> __linktime_error() does the same thing as __compiletime_error() and is
>> only used in bug.h.  Since the macro defines a function attribute that
>> will cause a failure at compile-time (not link-time), it makes more
>> sense to keep __compiletime_error(), which is also neatly mated with
>> __compiletime_warning().
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Why not change bug.h in the same commit?  Or alternatively, why not
> change it first?
I'm still new to this project's development process and wasn't sure if
those two changes would be considered lumping multiple changes together
or not.  So that type of lumping is acceptable then?  I certainly
wouldn't mind squashing them.
> Getting rid of __linktime_error *before* changing its
> use in bug.h to __compiletime_error seems wrong.
Good point!

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Daniel Santos]

On 09/28/2012 07:26 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote:
>> --- a/include/linux/compiler-gcc4.h
>> +++ b/include/linux/compiler-gcc4.h
>> @@ -15,7 +15,12 @@
>>  
>>  #if GCC_VERSION >= 40102
>>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>> -#endif
>> +
>> +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/
>> +# if GCC_VERSION != 40600
>> +#  define __flatten __attribute__((flatten))
>> +# endif
>> +#endif /* GCC_VERSION >= 40102 */
> Same comment as before: why 40102 rather than 40100?
Again, I'm presuming building with 4.1.0 or 4.1.1 will always have the
build broken earlier.  I don't have any objections to changing this, but
it would seem that the issue with the __weak attribute needs to be resolved.

Daniel

Re: [Bulk] Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Josh Triplett]

On Fri, Sep 28, 2012 at 07:31:53PM -0500, Daniel Santos wrote:
> On 09/28/2012 07:20 PM, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote:
> >> --- a/include/linux/compiler-gcc4.h
> >> +++ b/include/linux/compiler-gcc4.h
> >> @@ -13,11 +13,11 @@
> >>  #define __must_check 		__attribute__((warn_unused_result))
> >>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
> >>  
> >> -#if __GNUC_MINOR__ > 0
> >> +#if GCC_VERSION >= 40102
> >>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> >>  #endif
> > You've changed the semantics of this one; if literally translated, this
> > should have become #if GCC_VERSION >= 40100.  If you intended to change
> > that, could you please document why?  And in any case, could you make
> > that semantic change in a separate commit from the switch to
> > GCC_VERSION?
> hmm, it looks like somebody commented out the #error that would normally
> prevent that test from ever occurring on 4.1.0 or 4.1.1.
> When I had written this patch, it wasn't commented out and I had assumed
> that it was obvious from the context.

GCC 4.1.0 and 4.1.1 miscompiling __weak has nothing to do with
__compiletime_object_size; why should *this* version check exclude those
versions?

- Josh Triplett

Re: [Bulk] Re: [PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros

[Josh Triplett]

On Fri, Sep 28, 2012 at 07:34:36PM -0500, Daniel Santos wrote:
> On 09/28/2012 07:23 PM, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote:
> >> __linktime_error() does the same thing as __compiletime_error() and is
> >> only used in bug.h.  Since the macro defines a function attribute that
> >> will cause a failure at compile-time (not link-time), it makes more
> >> sense to keep __compiletime_error(), which is also neatly mated with
> >> __compiletime_warning().
> >>
> >> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > Why not change bug.h in the same commit?  Or alternatively, why not
> > change it first?
> I'm still new to this project's development process and wasn't sure if
> those two changes would be considered lumping multiple changes together
> or not.  So that type of lumping is acceptable then?  I certainly
> wouldn't mind squashing them.

In general, you shouldn't make *unrelated* changes in the same patch,
and you should definitely make fine-grained patches whenever
appropriate.  However, in this case the changes seem quite related.

The rule in the Linux kernel: the kernel should compile and function
after every individual patch.  You shouldn't introduce breakage in a
patch series and fix it later in that series.  Commonly called making
your patch series "bisectable", since it helps "git bisect" work more
smoothly to have every single git commit compile and run.  In this case,
you removed __linktime_error before removing its caller.

> > Getting rid of __linktime_error *before* changing its
> > use in bug.h to __compiletime_error seems wrong.
> Good point!

Thinking about it further, in this case I think it makes sense to just
reverse the two patches: remove the one and only use of
__linktime_error, then remove its definition.

- Josh Triplett

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Josh Triplett]

On Fri, Sep 28, 2012 at 07:38:32PM -0500, Daniel Santos wrote:
> On 09/28/2012 07:26 PM, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote:
> >> --- a/include/linux/compiler-gcc4.h
> >> +++ b/include/linux/compiler-gcc4.h
> >> @@ -15,7 +15,12 @@
> >>  
> >>  #if GCC_VERSION >= 40102
> >>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> >> -#endif
> >> +
> >> +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/
> >> +# if GCC_VERSION != 40600
> >> +#  define __flatten __attribute__((flatten))
> >> +# endif
> >> +#endif /* GCC_VERSION >= 40102 */
> > Same comment as before: why 40102 rather than 40100?
> Again, I'm presuming building with 4.1.0 or 4.1.1 will always have the
> build broken earlier.  I don't have any objections to changing this, but
> it would seem that the issue with the __weak attribute needs to be resolved.

That issue doesn't relate to __flatten, though; it only relates to
__weak.  Since __flatten (and __compiletime_object_size) will work fine
on 4.1.0 and 4.1.1, don't exclude them just because the definition for
__weak elsewhere in the file excludes them.  That just makes it harder
for anyone who might want to work on the issue with __weak.

- Josh Triplett

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

On 09/28/2012 07:32 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
>> Negative sized arrays wont create a compile-time error in some cases
>> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
>> the error function attribute that will.  This patch modifies
>> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
>> function attribute so that you don't have to build the entire kernel to
>> discover that you have a problem, and then enjoy trying to track it down
>> from a link-time error.
> Rather than doing both, and potentially producing two errors for the
> same issue, how about using __compiletime_error only, and only using the
> negative-sized array when __compiletime_error has no useful definition?
>
> For instance, in compiler.h, when defining __compiletime_error as an
> empty macro in the fallback case, you could define a
> __compiletime_error_fallback() macro that declares a negative-sized
> array; you could then define __compiletime_error_fallback() as an empty
> macro when it doesn't exist.
Oh, that's a great idea.  That will keep more of the compiler's details
in compiler*.h.

Daniel

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Steven Rostedt]

On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > ---
> >  include/linux/bug.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index aaac4bb..298a916 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
> >  #define BUILD_BUG()						\
> >  	do {							\
> >  		extern void __build_bug_failed(void)		\
> > -			__linktime_error("BUILD_BUG failed");	\
> > +			__compiletime_error("BUILD_BUG failed");\
> >  		__build_bug_failed();				\
> >  	} while (0)
> 
> This change should either occur as part of patch 5 or before patch 5,
> not after.

I noticed the same thing and was about to comment on it.

Please do not break bisectablity. All your patches should compile and
run at every step.

-- Steve

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

On 09/28/2012 07:32 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
>> Negative sized arrays wont create a compile-time error in some cases
>> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
>> the error function attribute that will.  This patch modifies
>> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
>> function attribute so that you don't have to build the entire kernel to
>> discover that you have a problem, and then enjoy trying to track it down
>> from a link-time error.
>
> Rather than doing both, and potentially producing two errors for the
> same issue, how about using __compiletime_error only, and only using the
> negative-sized array when __compiletime_error has no useful definition?
>
> For instance, in compiler.h, when defining __compiletime_error as an
> empty macro in the fallback case, you could define a
> __compiletime_error_fallback() macro that declares a negative-sized
> array; you could then define __compiletime_error_fallback() as an empty
> macro when it doesn't exist.
It may also make sense to define
#define BUILD_BUG() BUILD_BUG_ON(1)

I haven't examined this really closely yet and my eyes are getting a
little bleary :)


Really, I would have liked to be able to set the error message as
well, but we would have to have the macro generate a unique function
name for each time its expanded to make that work.  Example:

#define BUILD_BUG_ON(cond) BUILD_BUG_ON_MSG(cond, #cond)
#define BUILD_BUG_ON_MSG(cond, msg)                                \
    do {                                                           \
        extern void __build_bug_on_failed ## something_unique(void)\
            __compiletime_error("BUILD_BUG_ON failed: " msg);      \
        __compiletime_error_fallback(cond);                        \
        if (cond)                                                  \
            __build_bug_on_failed();                               \
    } while(0)

I just don't know any tricks to generate unique pre-processor
value automatically.

Daniel

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Josh Triplett]

On Fri, Sep 28, 2012 at 08:26:08PM -0500, Daniel Santos wrote:
> On 09/28/2012 07:32 PM, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
> >> Negative sized arrays wont create a compile-time error in some cases
> >> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> >> the error function attribute that will.  This patch modifies
> >> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> >> function attribute so that you don't have to build the entire kernel to
> >> discover that you have a problem, and then enjoy trying to track it down
> >> from a link-time error.
> >
> > Rather than doing both, and potentially producing two errors for the
> > same issue, how about using __compiletime_error only, and only using the
> > negative-sized array when __compiletime_error has no useful definition?
> >
> > For instance, in compiler.h, when defining __compiletime_error as an
> > empty macro in the fallback case, you could define a
> > __compiletime_error_fallback() macro that declares a negative-sized
> > array; you could then define __compiletime_error_fallback() as an empty
> > macro when it doesn't exist.
> It may also make sense to define
> #define BUILD_BUG() BUILD_BUG_ON(1)
> 
> I haven't examined this really closely yet and my eyes are getting a
> little bleary :)
> 
> 
> Really, I would have liked to be able to set the error message as
> well, but we would have to have the macro generate a unique function
> name for each time its expanded to make that work.  Example:
> 
> #define BUILD_BUG_ON(cond) BUILD_BUG_ON_MSG(cond, #cond)
> #define BUILD_BUG_ON_MSG(cond, msg)                                \
>     do {                                                           \
>         extern void __build_bug_on_failed ## something_unique(void)\
>             __compiletime_error("BUILD_BUG_ON failed: " msg);      \
>         __compiletime_error_fallback(cond);                        \
>         if (cond)                                                  \
>             __build_bug_on_failed();                               \
>     } while(0)
> 
> I just don't know any tricks to generate unique pre-processor
> value automatically.

Assuming you don't call BUILD_BUG_ON_MSG more than once per line:

/tmp$ cat test.c
#define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
    do { \
        extern void __build_bug_on_failed_ ## line (void) __attribute__((error(msg))); \
        if (cond) \
            __build_bug_on_failed_ ## line(); \
    } while (0)

#define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line) BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
#define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg, __LINE__)

void f(void)
{
    BUILD_BUG_ON_MSG(0, "test 1");
    BUILD_BUG_ON_MSG(1, "test 2");
    BUILD_BUG_ON_MSG(0, "test 3");
    BUILD_BUG_ON_MSG(1, "test 4");
}
/tmp$ gcc -c test.c
test.c: In function ‘f’:
test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with attribute error: test 2
test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with attribute error: test 4

- Josh Triplett

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Borislav Petkov]

On Fri, Sep 28, 2012 at 06:20:04PM -0500, Daniel Santos wrote:
> Throughout compiler*.h, many version checks are made.  These can be
> simplified by using the macro that gcc's documentation recommends.
> However, my primary reason for adding this is that I need bug-check
> macros that are enabled at certain gcc versions and it's cleaner to use
> this macro than the tradition method:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)
> 
> If you add patch level, it gets this ugly:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
>    __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))
> 
> As opposed to:
> 
> if GCC_VERSION >= 40201
> 
> While having separate headers for gcc 3 & 4 eliminates some of this
> verbosity, they can still be cleaned up by this.

Yes,

very fine readability improvement.

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
    Boris.

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Borislav Petkov]

On Fri, Sep 28, 2012 at 09:04:35PM -0400, Steven Rostedt wrote:
> On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> > > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > > ---
> > >  include/linux/bug.h |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > > index aaac4bb..298a916 100644
> > > --- a/include/linux/bug.h
> > > +++ b/include/linux/bug.h
> > > @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
> > >  #define BUILD_BUG()						\
> > >  	do {							\
> > >  		extern void __build_bug_failed(void)		\
> > > -			__linktime_error("BUILD_BUG failed");	\
> > > +			__compiletime_error("BUILD_BUG failed");\
> > >  		__build_bug_failed();				\
> > >  	} while (0)
> > 
> > This change should either occur as part of patch 5 or before patch 5,
> > not after.
> 
> I noticed the same thing and was about to comment on it.
> 
> Please do not break bisectablity. All your patches should compile and
> run at every step.

And while we're at it, every patch upstream should have a commit message
explaining why this is done. No matter how trivial it is, because after
a sufficient amount of time passes, everyone tends to forget why this
has been done.

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Daniel Santos]

On 09/30/2012 08:22 AM, Borislav Petkov wrote:
> On Fri, Sep 28, 2012 at 09:04:35PM -0400, Steven Rostedt wrote:
>> On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
>>> On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
>>>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>>>> ---
>>>>  include/linux/bug.h |    2 +-
>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>>>> index aaac4bb..298a916 100644
>>>> --- a/include/linux/bug.h
>>>> +++ b/include/linux/bug.h
>>>> @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
>>>>  #define BUILD_BUG()						\
>>>>  	do {							\
>>>>  		extern void __build_bug_failed(void)		\
>>>> -			__linktime_error("BUILD_BUG failed");	\
>>>> +			__compiletime_error("BUILD_BUG failed");\
>>>>  		__build_bug_failed();				\
>>>>  	} while (0)
>>> This change should either occur as part of patch 5 or before patch 5,
>>> not after.
>> I noticed the same thing and was about to comment on it.
>>
>> Please do not break bisectablity. All your patches should compile and
>> run at every step.
> And while we're at it, every patch upstream should have a commit message
> explaining why this is done. No matter how trivial it is, because after
> a sufficient amount of time passes, everyone tends to forget why this
> has been done.
>
> Thanks.
>
Ah, well thank you all for the guidance!

Daniel

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Daniel Santos]

So in light of feedback I've been getting on this patch set, it leaves
me with
this question.
> +#define GCC_VERSION (__GNUC__ * 10000 \
> +		   + __GNUC_MINOR__ * 100 \
> +		   + __GNUC_PATCHLEVEL__)
This macro presumes you are using gcc 3.0 or later, which introduced the
__GNUC_PATCHLEVEL__ predefined macro.  Should you be using a version of gcc
prior to 3.0 (where the macro is undefined), you would get an error that
__GNUC_PATCHLEVEL__ is undefined prior to getting the error trying to
include
"linux/compiler-gcc2.h".  So it presumes the compiler is 3.0+, when another
part of the code may allow it from a future change.  Should it be
modified to
do account for this or would that be overkill?


#ifdef __GNUC_PATCHLEVEL__
# define GCC_VERSION (__GNUC__ * 10000 \
                    + __GNUC_MINOR__ * 100 \
                    + __GNUC_PATCHLEVEL__)
#else
# define GCC_VERSION (__GNUC__ * 10000 \
                    + __GNUC_MINOR__ * 100)
#endif

Daniel

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

On 09/28/2012 09:55 PM, Josh Triplett wrote:
> Assuming you don't call BUILD_BUG_ON_MSG more than once per line:
>
> /tmp$ cat test.c
> #define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
>     do { \
>         extern void __build_bug_on_failed_ ## line (void) __attribute__((error(msg))); \
>         if (cond) \
>             __build_bug_on_failed_ ## line(); \
>     } while (0)
>
> #define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line) BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
> #define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg, __LINE__)
>
> void f(void)
> {
>     BUILD_BUG_ON_MSG(0, "test 1");
>     BUILD_BUG_ON_MSG(1, "test 2");
>     BUILD_BUG_ON_MSG(0, "test 3");
>     BUILD_BUG_ON_MSG(1, "test 4");
> }
> /tmp$ gcc -c test.c
> test.c: In function ‘f’:
> test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with attribute error: test 2
> test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with attribute error: test 4
Thanks! This is very nice!  I've done a little more research and
discovered that there's also a __COUNTER__ macro that is available
in gcc 4.3+.  Before I realized that it was only available in gcc
4.3, I wrote this little macro:

#define _CONCAT1(a, b) a##b
#define CONCAT(a, b) _CONCAT1(a, b)

#ifdef __COUNTER__
# define UNIQUIFY(prefix) CONCAT(prefix, __COUNTER__)
#else
# define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
#endif

However, this could lead to code might compile on gcc 4.3+, but
not compile prior, so this is bad, right?

Daniel

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Josh Triplett]

On Sun, Sep 30, 2012 at 06:11:01PM -0500, Daniel Santos wrote:
> So in light of feedback I've been getting on this patch set, it leaves
> me with
> this question.
> > +#define GCC_VERSION (__GNUC__ * 10000 \
> > +		   + __GNUC_MINOR__ * 100 \
> > +		   + __GNUC_PATCHLEVEL__)
> This macro presumes you are using gcc 3.0 or later, which introduced the
> __GNUC_PATCHLEVEL__ predefined macro.  Should you be using a version of gcc
> prior to 3.0 (where the macro is undefined), you would get an error that
> __GNUC_PATCHLEVEL__ is undefined prior to getting the error trying to
> include
> "linux/compiler-gcc2.h".  So it presumes the compiler is 3.0+, when another
> part of the code may allow it from a future change.  Should it be
> modified to
> do account for this or would that be overkill?

Overkill, since Linux requires GCC 3.2 or newer.  From compiler-gcc3.h:

#if __GNUC_MINOR__ < 2
# error Sorry, your compiler is too old - please upgrade it.
#endif

- Josh Triplett

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Josh Triplett]

On Sun, Sep 30, 2012 at 06:29:01PM -0500, Daniel Santos wrote:
> On 09/28/2012 09:55 PM, Josh Triplett wrote:
> > Assuming you don't call BUILD_BUG_ON_MSG more than once per line:
> >
> > /tmp$ cat test.c
> > #define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
> >     do { \
> >         extern void __build_bug_on_failed_ ## line (void) __attribute__((error(msg))); \
> >         if (cond) \
> >             __build_bug_on_failed_ ## line(); \
> >     } while (0)
> >
> > #define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line) BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
> > #define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg, __LINE__)
> >
> > void f(void)
> > {
> >     BUILD_BUG_ON_MSG(0, "test 1");
> >     BUILD_BUG_ON_MSG(1, "test 2");
> >     BUILD_BUG_ON_MSG(0, "test 3");
> >     BUILD_BUG_ON_MSG(1, "test 4");
> > }
> > /tmp$ gcc -c test.c
> > test.c: In function ‘f’:
> > test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with attribute error: test 2
> > test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with attribute error: test 4
> Thanks! This is very nice!  I've done a little more research and
> discovered that there's also a __COUNTER__ macro that is available
> in gcc 4.3+.  Before I realized that it was only available in gcc
> 4.3, I wrote this little macro:
> 
> #define _CONCAT1(a, b) a##b
> #define CONCAT(a, b) _CONCAT1(a, b)
> 
> #ifdef __COUNTER__
> # define UNIQUIFY(prefix) CONCAT(prefix, __COUNTER__)
> #else
> # define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> #endif
> 
> However, this could lead to code might compile on gcc 4.3+, but
> not compile prior, so this is bad, right?

Yes, as long as Linux continues to support prior GCC versions (currently
anything 3.2 or newer), I'd suggest sticking with __LINE__ so that it
consistently breaks if you use more than one BUILD_BUG_ON_MSG per line.

Good to know that __COUNTER__ exists, though.

Also, the name BUILD_BUG_ON_MSG seems wrong to me somehow; I keep
parsing it as though something about the message causes the build bug.

- Josh Triplett

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Michel Lespinasse]

On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will.  This patch modifies
> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> function attribute so that you don't have to build the entire kernel to
> discover that you have a problem, and then enjoy trying to track it down
> from a link-time error.

Few other alternatives I've seen used in other projects (from memory,
so I may have gotten the details wrong):

1) if (condition) { __asm__(".error \"Some error message\""); }
2) switch (0) {
    case 0: break;
    case !condition: break;
    }
    (fails to compile if !condition evaluates to 0)

If you can get the first suggestion to work it'd be nice, as you could
get some descriptive error message (you can add the line number there
too).

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [PATCH 10/10] bug.h: Add gcc 4.2+ versions of BUILD_BUG_ON_* macros

[Michel Lespinasse]

On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
> BUILD_BUG_ON42(arg)
> BUILD_BUG_ON_CONST42(arg)
>
> Prior to gcc 4.2, the optimizer was unable to determine that many
> constant values stored in structs were indeed compile-time constants and
> optimize them out.  Sometimes, it will find an intergral value to be a
> compile-time constant, but fail to perform a bit-wise AND at
> compile-time.  These two macros provide a mechanism to perform these
> build-time checks, but not break on older compilers where we already
> know they can't be checked at compile time.
>
> For specific details, consult the doc comments for BUILD_BUG_ON_CONST.
> These macros are used in the generic rbtree code.

I think the names are quite confusing. BUILD_BUG_ON_NON_CONST42 sounds
like it's checking if 42 is a constant.

The name probably shouldn't mention what compiler versions support
this check, but instead it should hint as to when you should use this
instead of BUILD_BUG_ON_CONST ? Maybe BUILD_BUG_ON_CONST_DEREF or
something (I'm pretty bad with names too :)

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

On 10/01/2012 07:48 PM, Michel Lespinasse wrote:
> On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
>> Negative sized arrays wont create a compile-time error in some cases
>> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
>> the error function attribute that will.  This patch modifies
>> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
>> function attribute so that you don't have to build the entire kernel to
>> discover that you have a problem, and then enjoy trying to track it down
>> from a link-time error.
> Few other alternatives I've seen used in other projects (from memory,
> so I may have gotten the details wrong):
>
> 1) if (condition) { __asm__(".error \"Some error message\""); }
> 2) switch (0) {
>     case 0: break;
>     case !condition: break;
>     }
>     (fails to compile if !condition evaluates to 0)
>
> If you can get the first suggestion to work it'd be nice, as you could
> get some descriptive error message (you can add the line number there
> too).
Thanks for this info.  I'm still pretty noob-ish in modern assembly, but
is the .error directive available on all supported assemblers?  It
appears to have been added to GNU binutils in version 2.16 from what I
can tell (http://sourceware.org/binutils/docs-2.16/as/Error.html).  If
it is supported, I would definitely prefer that one as a fallback option.

I did a search on sources for the regex \.error\s+\\?" and didn't turn
up anything outside of arch/, so I'm guessing this may not be completely
portable.  Note also that these BUILD_BUG* macros do emit an error
message on gcc 4.3+ using __attribute__((error("msg"))).

Daniel

Re: [PATCH 10/10] bug.h: Add gcc 4.2+ versions of BUILD_BUG_ON_* macros

[Daniel Santos]

On 10/01/2012 07:55 PM, Michel Lespinasse wrote:
> On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
>> BUILD_BUG_ON42(arg)
>> BUILD_BUG_ON_CONST42(arg)
>>
>> Prior to gcc 4.2, the optimizer was unable to determine that many
>> constant values stored in structs were indeed compile-time constants and
>> optimize them out.  Sometimes, it will find an intergral value to be a
>> compile-time constant, but fail to perform a bit-wise AND at
>> compile-time.  These two macros provide a mechanism to perform these
>> build-time checks, but not break on older compilers where we already
>> know they can't be checked at compile time.
>>
>> For specific details, consult the doc comments for BUILD_BUG_ON_CONST.
>> These macros are used in the generic rbtree code.
>
> I think the names are quite confusing. BUILD_BUG_ON_NON_CONST42 sounds
> like it's checking if 42 is a constant.
>
> The name probably shouldn't mention what compiler versions support
> this check, but instead it should hint as to when you should use this
> instead of BUILD_BUG_ON_CONST ? Maybe BUILD_BUG_ON_CONST_DEREF or
> something (I'm pretty bad with names too :)
I completely agree about the naming, but I'm also stumped. I choose
version 4.2 after writing a test program & group of scripts and sifting
through the results of 220k tests of __builtin_constant_p()!  In gcc
4.2, there are still some tests that will fail, but I went with 4.2 as
the "good version" mostly because:

a. the broken tests didn't affect my generic red-black tree
implementation, and
b. broken cases in 4.2 were the slim minority.

For instance calling __builtin_constant_p() on a dereferenced pointer in
4.2 always fails, while dereferencing a global static array (of
primitives) returns 1 in pretty much every case that it should
(excepting global non-static const, which also fails in 4.7 and perhaps
the compiler figures that somewhere else, const can be cast away and the
data modified anyway?).

Maybe it would be better in the long term to create multiple macros for
testing various constructs.  Verbosity does really start to increase
here, but I suppose we can work out some type of nomenclature to control
that while still being clear about what the macro does (not that I have
any ideas at the moment).

BUILD_BUG_ON_NON_CONST_PTR_DEREF     - gcc 4.4
BUILD_BUG_ON_NON_CONST_ARRAY_DEREF   - gcc 4.2
BUILD_BUG_ON_NON_CONST_STRUCT_MEMBER - gcc 4.2 (unless it's a pointer or
you use -O1)
etc.

To make it any more clear, I suppose I will have to clean up my test
results and share them again (an 82k spreadsheet uncompressed).  Let me
know if you want to see it.  So it's really for a sort of
full-disclosure that I use the suffix "42" and not something more
specific to what it should test.

Alternately, we can just call it something like
BUILD_BUG_ON_NON_CONST_MODERN and bump the version up gcc 4.4, which is
just as functional as 4.7.

Daniel

Re: [PATCH 1/10] compiler-gcc4.h: correct verion check for __compiletime_error

[David Rientjes]

On Fri, 28 Sep 2012, Daniel Santos wrote:

> NOTE: this is has already been comitted to -mm
> 
> __attribute__((error(msg))) was introduced in gcc 4.3 (not 4.4) and as I
> was unable to find any gcc bugs pertaining to it, I'm presuming that it
> has functioned as advertised since 4.3.0.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Tested-by: David Rientjes <rientjes@google.com>

Works with 4.3.6.

Re: [PATCH 2/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[David Rientjes]

On Fri, 28 Sep 2012, Daniel Santos wrote:

> This helps to keep the file from getting confusing, removes one
> duplicate version check and should encourage future editors to put new
> macros where they belong.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: David Rientjes <rientjes@google.com>

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[David Rientjes]

On Fri, 28 Sep 2012, Daniel Santos wrote:

> Throughout compiler*.h, many version checks are made.  These can be
> simplified by using the macro that gcc's documentation recommends.
> However, my primary reason for adding this is that I need bug-check
> macros that are enabled at certain gcc versions and it's cleaner to use
> this macro than the tradition method:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)
> 
> If you add patch level, it gets this ugly:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
>    __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))
> 
> As opposed to:
> 
> if GCC_VERSION >= 40201
> 
> While having separate headers for gcc 3 & 4 eliminates some of this
> verbosity, they can still be cleaned up by this.
> 
> See also:
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: David Rientjes <rientjes@google.com>

Re: [Bulk] Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[David Rientjes]

On Fri, 28 Sep 2012, Josh Triplett wrote:

> GCC 4.1.0 and 4.1.1 miscompiling __weak has nothing to do with
> __compiletime_object_size; why should *this* version check exclude those
> versions?
> 

Agreed, we shouldn't be relying on any #error directives to fail the build 
and then try to factor those version numbers out of other directives; if 
the #error directive were ever to be removed (or commented out, like in 
this case), nobody would make the other directives inclusive of that 
now-allowed version where things like __compiletime_object_size() are 
valid.

After __compiletime_object_size() is compiled for GCC_VERSION >= 40100, 
then:

	Acked-by: David Rientjes <rientjes@google.com>

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[David Rientjes]

On Fri, 28 Sep 2012, Daniel Santos wrote:

> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

After this is folded into the previous patch in the series, 
"compiler{,-gcc4}.h: Remove duplicate macros", then:

	Acked-by: David Rientjes <rientjes@google.com>

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[David Rientjes]

On Fri, 28 Sep 2012, Josh Triplett wrote:

> That issue doesn't relate to __flatten, though; it only relates to
> __weak.  Since __flatten (and __compiletime_object_size) will work fine
> on 4.1.0 and 4.1.1, don't exclude them just because the definition for
> __weak elsewhere in the file excludes them.  That just makes it harder
> for anyone who might want to work on the issue with __weak.
> 

Nack to the patch since there are no users of it; there's no need to 
define every possible gcc function attribute.  If anything actually needs 
to use __attribute__((flatten)), then it can introduce it.

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Josh Triplett]

On Tue, Oct 02, 2012 at 11:49:03PM -0700, David Rientjes wrote:
> On Fri, 28 Sep 2012, Josh Triplett wrote:
> 
> > That issue doesn't relate to __flatten, though; it only relates to
> > __weak.  Since __flatten (and __compiletime_object_size) will work fine
> > on 4.1.0 and 4.1.1, don't exclude them just because the definition for
> > __weak elsewhere in the file excludes them.  That just makes it harder
> > for anyone who might want to work on the issue with __weak.
> > 
> 
> Nack to the patch since there are no users of it; there's no need to 
> define every possible gcc function attribute.  If anything actually needs 
> to use __attribute__((flatten)), then it can introduce it.

This patch series started out as part of another patch series by Daniel
Santos that makes use of __flatten; I think Daniel plans to have that
patch series depend on this one.  Thus, I think it makes sense to
introduce __flatten at this point.

- Josh Triplett

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[David Rientjes]

On Tue, 2 Oct 2012, Josh Triplett wrote:

> This patch series started out as part of another patch series by Daniel
> Santos that makes use of __flatten; I think Daniel plans to have that
> patch series depend on this one.  Thus, I think it makes sense to
> introduce __flatten at this point.
> 

Daniel, please introduce __flatten in the patch series that uses it, 
thanks.

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Daniel Santos]

On 10/03/2012 02:53 AM, David Rientjes wrote:
> On Tue, 2 Oct 2012, Josh Triplett wrote:
>
>> This patch series started out as part of another patch series by Daniel
>> Santos that makes use of __flatten; I think Daniel plans to have that
>> patch series depend on this one.  Thus, I think it makes sense to
>> introduce __flatten at this point.
>>
>
> Daniel, please introduce __flatten in the patch series that uses it, 
> thanks.
That isn't going to work. I split my patches out into three sets
because, otherwise, the list of maintainers that must be CCed exceeds
the allowable size of the LKML server and my messages get tagged as
spam, causing untold confusion as messages reach maintainers, but not
the LKML.  Please note from the summary of this patch set
(https://lkml.org/lkml/2012/9/28/1136)
> This patch set is a dependency of the generic red-black tree patch set, which
> I have now split up into three smaller sets.
And the patch set this depends upon was submitted 9/28 as well
(https://lkml.org/lkml/2012/9/28/1183) and the summary starts with this
text:
> This patch set depends upon the following:
> * Cleanup & new features for compiler*.h and bug.h
> * kernel-doc bug fixes (for generating docs)
If I move this patch to the other patch set, scripts/get_maintainers.pl will give me a list longer than the LKML administrator will allow for recipients (1024 bytes max)


On 09/28/2012 12:46 PM, David Miller wrote:
> From: Daniel Santos <danielfsantos@att.net>
> Date: Fri, 28 Sep 2012 09:22:52 -0500
>
>> Hello. I'm trying to send a patch set and people in my TO list are
>> receiving the emails, but not the LKML.
> You can't have email fields larger than 1024 characters, that CC:
> list is way too large.  There is never any legitimate reason to
> CC: so many people, and we block such long email fields since
> %99.99999 they indicate spam.
If you have any other reasonable suggestions, please post them.

Thanks,
Daniel

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Daniel Santos]

On 10/03/2012 01:44 AM, David Rientjes wrote:
> On Fri, 28 Sep 2012, Daniel Santos wrote:
>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> After this is folded into the previous patch in the series, 
> "compiler{,-gcc4}.h: Remove duplicate macros", then:
>
> 	Acked-by: David Rientjes <rientjes@google.com>
Thanks.  I've actually just reversed the patch order per Josh's
suggestion and added patch comments to it.  I can squash them if you
guys prefer.

Unfortunately, I'm a bit confused as to how I should re-submit these,
still being new to this project.  Patch 1 is already in -mm. Patches 2-3
have not changed. I've made a correction to patch #4 and reversed the
order of 5 & 6. And what was 8-10 is now 8-15, as I've completely
re-done BUILD_BUG_ON.  I was planning on just submitting the whole set
again, is this the correct protocol?  If so, should I reply to the
original [PATCH 0/10] thread or create a new one?

Thanks!
Daniel

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Steven Rostedt]

On Wed, 2012-10-03 at 06:20 -0500, Daniel Santos wrote:

> > Daniel, please introduce __flatten in the patch series that uses it, 
> > thanks.
> That isn't going to work. I split my patches out into three sets
> because, otherwise, the list of maintainers that must be CCed exceeds
> the allowable size of the LKML server and my messages get tagged as
> spam, causing untold confusion as messages reach maintainers, but not
> the LKML.  Please note from the summary of this patch set
> (https://lkml.org/lkml/2012/9/28/1136)

That's not a valid reason to not included it with the other patch
series.

> > This patch set is a dependency of the generic red-black tree patch set, which
> > I have now split up into three smaller sets.
> And the patch set this depends upon was submitted 9/28 as well
> (https://lkml.org/lkml/2012/9/28/1183) and the summary starts with this
> text:
> > This patch set depends upon the following:
> > * Cleanup & new features for compiler*.h and bug.h
> > * kernel-doc bug fixes (for generating docs)
> If I move this patch to the other patch set,
> scripts/get_maintainers.pl will give me a list longer than the LKML
> administrator will allow for recipients (1024 bytes max)

You don't need to use get_maintainers. It's more of a help tool to find
maintainers and not something that is mandatory. Not everyone that has
ever touched one of these files needs to be Cc'd.

Please move the patch to the patch series where it is used. Otherwise it
confuses reviewers as it did here.

-- Steve

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Daniel Santos]

On 10/03/2012 09:01 AM, Steven Rostedt wrote:
> On Wed, 2012-10-03 at 06:20 -0500, Daniel Santos wrote:
>
>>> Daniel, please introduce __flatten in the patch series that uses it, 
>>> thanks.
>> That isn't going to work. I split my patches out into three sets
>> because, otherwise, the list of maintainers that must be CCed exceeds
>> the allowable size of the LKML server and my messages get tagged as
>> spam, causing untold confusion as messages reach maintainers, but not
>> the LKML.  Please note from the summary of this patch set
>> (https://lkml.org/lkml/2012/9/28/1136)
> That's not a valid reason to not included it with the other patch
> series.
>
>>> This patch set is a dependency of the generic red-black tree patch set, which
>>> I have now split up into three smaller sets.
>> And the patch set this depends upon was submitted 9/28 as well
>> (https://lkml.org/lkml/2012/9/28/1183) and the summary starts with this
>> text:
>>> This patch set depends upon the following:
>>> * Cleanup & new features for compiler*.h and bug.h
>>> * kernel-doc bug fixes (for generating docs)
>> If I move this patch to the other patch set,
>> scripts/get_maintainers.pl will give me a list longer than the LKML
>> administrator will allow for recipients (1024 bytes max)
> You don't need to use get_maintainers. It's more of a help tool to find
> maintainers and not something that is mandatory. Not everyone that has
> ever touched one of these files needs to be Cc'd.
>
> Please move the patch to the patch series where it is used. Otherwise it
> confuses reviewers as it did here.
Ok then, but this would also apply to the addition of these macros as well:
BUILD_BUG_ON_NON_CONST
BUILD_BUG42
BUILD_BUG_ON_NON_CONST42

Should these then also be moved?
Should I only CC those who have responded to these patches and whomever
is in the MAINTAINERS file then?

Thanks
Daniel

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Steven Rostedt]

On Wed, 2012-10-03 at 09:46 -0500, Daniel Santos wrote:

> > Please move the patch to the patch series where it is used. Otherwise it
> > confuses reviewers as it did here.
> Ok then, but this would also apply to the addition of these macros as well:
> BUILD_BUG_ON_NON_CONST
> BUILD_BUG42
> BUILD_BUG_ON_NON_CONST42
> 
> Should these then also be moved?

If they are only used by the other patch set, sure.

> Should I only CC those who have responded to these patches and whomever
> is in the MAINTAINERS file then?

Yep. I personally never use the get_maintainers script. I first check
the MAINTAINERS file. If the subsystem I'm working on exists there, I
only email those that are listed there, including any mailing lists that
are mentioned (as well as LKML). If it's not listed, I then do a git log
and see who does the most sign offs to changes there, and to what kind
of changes. I usually ignore the trivial stuff.

-- Steve

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Peter Zijlstra]

On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
> 
> Yep. I personally never use the get_maintainers script. I first check
> the MAINTAINERS file. If the subsystem I'm working on exists there, I
> only email those that are listed there, including any mailing lists that
> are mentioned (as well as LKML). If it's not listed, I then do a git log
> and see who does the most sign offs to changes there, and to what kind
> of changes. I usually ignore the trivial stuff. 

I also tend to suggest doing git-blame to see who touched the code being
changed last.

As a maintainer I frequently get to fwd/bounce patches because of
missing CCs like that.

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Josh Triplett]

On Wed, Oct 03, 2012 at 06:49:10AM -0500, Daniel Santos wrote:
> On 10/03/2012 01:44 AM, David Rientjes wrote:
> > On Fri, 28 Sep 2012, Daniel Santos wrote:
> >
> >> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > After this is folded into the previous patch in the series, 
> > "compiler{,-gcc4}.h: Remove duplicate macros", then:
> >
> > 	Acked-by: David Rientjes <rientjes@google.com>
> Thanks.  I've actually just reversed the patch order per Josh's
> suggestion and added patch comments to it.  I can squash them if you
> guys prefer.
> 
> Unfortunately, I'm a bit confused as to how I should re-submit these,
> still being new to this project.  Patch 1 is already in -mm. Patches 2-3
> have not changed. I've made a correction to patch #4 and reversed the
> order of 5 & 6. And what was 8-10 is now 8-15, as I've completely
> re-done BUILD_BUG_ON.  I was planning on just submitting the whole set
> again, is this the correct protocol?  If so, should I reply to the
> original [PATCH 0/10] thread or create a new one?

Make your cover letter a reply to the original PATCH 0/10 mail,
generate your patches with git format-patch --subject-prefix=PATCHv2 ,
and include in the cover letter a patch series changelog saying what
changed in v2.

- Josh Triplett

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Joe Perches]

On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
> I first check
> the MAINTAINERS file. If the subsystem I'm working on exists there, I
> only email those that are listed there, including any mailing lists that
> are mentioned (as well as LKML). If it's not listed, I then do a git log
> and see who does the most sign offs to changes there, and to what kind
> of changes. I usually ignore the trivial stuff.

Funny because that's what the script does too.

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[David Rientjes]

On Wed, 3 Oct 2012, Daniel Santos wrote:

> Thanks.  I've actually just reversed the patch order per Josh's
> suggestion and added patch comments to it.  I can squash them if you
> guys prefer.
> 

No need to be so fine-grained in your patches, if you're trying to replace 
__linktime_error with __compiletime_error, which happens to be the title 
of the patch (and should remain the title), then just remove it's single 
occurrence and its definition at the same time with a clear changelog that 
__compiletime_error is sufficient.  No need to have two small patches with 
the same motivation.

> Unfortunately, I'm a bit confused as to how I should re-submit these,
> still being new to this project.  Patch 1 is already in -mm. Patches 2-3
> have not changed. I've made a correction to patch #4 and reversed the
> order of 5 & 6. And what was 8-10 is now 8-15, as I've completely
> re-done BUILD_BUG_ON.  I was planning on just submitting the whole set
> again, is this the correct protocol?  If so, should I reply to the
> original [PATCH 0/10] thread or create a new one?
> 

You already have a patch in -mm, so you have to base your series on that 
tree.  Get the latest -mm tree from http://www.ozlabs.org/~akpm/mmotm/ and 
base the revised series on that tree, then send it off to 
Andrew Morton <akpm@linux-foundation.org> and cc the list and your 
reviewers.  People often find it helpful to make it clear that this is v2 
of the patchset and that it's based on -mm as a helpful pointer.

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Daniel Santos]

On 10/03/2012 01:26 PM, David Rientjes wrote:
> On Wed, 3 Oct 2012, Daniel Santos wrote:
>
>> Thanks.  I've actually just reversed the patch order per Josh's
>> suggestion and added patch comments to it.  I can squash them if you
>> guys prefer.
>>
> No need to be so fine-grained in your patches, if you're trying to replace 
> __linktime_error with __compiletime_error, which happens to be the title 
> of the patch (and should remain the title), then just remove it's single 
> occurrence and its definition at the same time with a clear changelog that 
> __compiletime_error is sufficient.  No need to have two small patches with 
> the same motivation.
Sounds good to me
>
>> Unfortunately, I'm a bit confused as to how I should re-submit these,
>> still being new to this project.  Patch 1 is already in -mm. Patches 2-3
>> have not changed. I've made a correction to patch #4 and reversed the
>> order of 5 & 6. And what was 8-10 is now 8-15, as I've completely
>> re-done BUILD_BUG_ON.  I was planning on just submitting the whole set
>> again, is this the correct protocol?  If so, should I reply to the
>> original [PATCH 0/10] thread or create a new one?
>>
> You already have a patch in -mm, so you have to base your series on that 
> tree.  Get the latest -mm tree from http://www.ozlabs.org/~akpm/mmotm/ and 
> base the revised series on that tree, then send it off to 
> Andrew Morton <akpm@linux-foundation.org> and cc the list and your 
> reviewers.  People often find it helpful to make it clear that this is v2 
> of the patchset and that it's based on -mm as a helpful pointer.
I have it checked out from git://git.cmpxchg.org/linux-mmotm.git, the
problem is that I cannot correctly test against that right now because I
get an oops (without my patches) when setting up LVM (same on -next, bug
report here https://bugzilla.kernel.org/show_bug.cgi?id=48241).  What
I'm thinking about doing is to rebase them against v3.6 again and test
them there, but it will require a few minor changes (due to walken's
patches not being present).  Still, it's better than no re-testing.
Daniel

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Steven Rostedt]

On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote:
> On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
> > I first check
> > the MAINTAINERS file. If the subsystem I'm working on exists there, I
> > only email those that are listed there, including any mailing lists that
> > are mentioned (as well as LKML). If it's not listed, I then do a git log
> > and see who does the most sign offs to changes there, and to what kind
> > of changes. I usually ignore the trivial stuff.
> 
> Funny because that's what the script does too.
> 

Really? It ignores the trivial stuff and only adds people that seem to
actually do real work on the file?

If that's the case, I doubt that it would have caused the huge Cc list
that Daniel sent out.

-- Steve

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Daniel Santos]

On 10/03/2012 07:32 PM, Steven Rostedt wrote:
> On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote:
>> On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
>>> I first check
>>> the MAINTAINERS file. If the subsystem I'm working on exists there, I
>>> only email those that are listed there, including any mailing lists that
>>> are mentioned (as well as LKML). If it's not listed, I then do a git log
>>> and see who does the most sign offs to changes there, and to what kind
>>> of changes. I usually ignore the trivial stuff.
>>
>> Funny because that's what the script does too.
>>
>
> Really? It ignores the trivial stuff and only adds people that seem to
> actually do real work on the file?
>
> If that's the case, I doubt that it would have caused the huge Cc list
> that Daniel sent out.
>
> -- Steve
Well, you run that on:
* include/linux/bug.h,
* include/linux/compiler{,-gcc{,3,4}}.h,
* include/linux/rbtree.h,
* tools/testing/selftests,
* Documentation/DocBook/kernel-api.tmpl and
* scripts/kernel-doc,
and it really starts to add up (that's currently 23 on mmotm, not including
myself). Now, add people already involved in the patch set, etc., and it
makes
its way to 30.  That's why I split the patch set up.

Daniel

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Michel Lespinasse]

On Wed, Oct 3, 2012 at 7:46 AM, Daniel Santos <danielfsantos@att.net> wrote:
> On 10/03/2012 09:01 AM, Steven Rostedt wrote:
>> You don't need to use get_maintainers. It's more of a help tool to find
>> maintainers and not something that is mandatory. Not everyone that has
>> ever touched one of these files needs to be Cc'd.
>>
>> Please move the patch to the patch series where it is used. Otherwise it
>> confuses reviewers as it did here.
> Ok then, but this would also apply to the addition of these macros as well:
> BUILD_BUG_ON_NON_CONST
> BUILD_BUG42
> BUILD_BUG_ON_NON_CONST42
>
> Should these then also be moved?

Yes, this would actually make things easier.

> Should I only CC those who have responded to these patches and whomever
> is in the MAINTAINERS file then?

There is no strong rule here, but generally get_maintainers returns
too many people. You want to trim down the list to something shorter;
a dozen people is the most I would consider (but for most patches a
half-dozen is already plenty).

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute

[Joe Perches]

On Wed, 2012-10-03 at 20:32 -0400, Steven Rostedt wrote:
> On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote:
> > On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
> > > I first check
> > > the MAINTAINERS file. If the subsystem I'm working on exists there, I
> > > only email those that are listed there, including any mailing lists that
> > > are mentioned (as well as LKML). If it's not listed, I then do a git log
> > > and see who does the most sign offs to changes there, and to what kind
> > > of changes. I usually ignore the trivial stuff.
> > 
> > Funny because that's what the script does too.
> > 
> 
> Really? It ignores the trivial stuff and only adds people that seem to
> actually do real work on the file?

Fundamentally, yes.
It's not as good as even a semi-skilled person of course.

> If that's the case, I doubt that it would have caused the huge Cc list
> that Daniel sent out.

Multiple files per patch, large recipient lists.

I generally use --no-git and --nogit-fallback

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[David Rientjes]

On Wed, 3 Oct 2012, Daniel Santos wrote:

> I have it checked out from git://git.cmpxchg.org/linux-mmotm.git, the
> problem is that I cannot correctly test against that right now because I
> get an oops (without my patches) when setting up LVM (same on -next, bug
> report here https://bugzilla.kernel.org/show_bug.cgi?id=48241).  What
> I'm thinking about doing is to rebase them against v3.6 again and test
> them there, but it will require a few minor changes (due to walken's
> patches not being present).  Still, it's better than no re-testing.
> Daniel
> 

I would cherry-pick the changes you already have for this patchset in -mm 
into Linus' latest tree, then base your new patchset on top of that 
modified tree.

[PATCH v2 0/10] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve the
manageability of of compiler features at various versions (when they are
broken, etc.), and to cleanup & add some needed features to bug.h.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701)
o Reorder all features based upon the version introduced (readability)
o Change all version checks to use GCC_VERSION
o Remove redundant __linktime_error

bug.h
o Improve BUILD_BUG_ON(expr) - Will now generate a compile-time error and in
  gcc-4.4+, also emits an error message containing the expression that failed.
o Add BUILD_BUG_ON_MSG(expr, msg) - Like BUILD_BUG_ON, except that you can
  specify the error message that is emitted (again, gcc-4.4+).
o Add BUILD_BUG_ON_INTERNAL(expr, fn, msg) - contains a generic implementation
  of BUILG_BUG_ON{_MSG}.
o Finally, the implementations of BUILD_BUG{,_ON,_ON_MSG} is consolidated,
  eliminating duplicate code.

[PATCH v2 01/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8721704..4506d65 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH v2 02/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 4506d65..bbfeb13 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 //#  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH v2 04/10] bug.h: directly include linux/compiler.h

[danielfsantos]

We are just including asm/bug.h and expecting that linux/compiler.h will
eventually be included to define __linktime_error (used in
BUILD_BUG_ON). This patch includes it directly for clarity and to avoid
the possibility of changes in <arch>/*/include/asm/bug.h being changed
or not including linux/compiler.h for some reason. (Later patches will
in this set use more macros defined in compiler*.h.)

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..4bd74d8 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
-- 
1.7.3.4

[PATCH v2 05/10] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 4bd74d8..a03c3ef 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -74,7 +74,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index bbfeb13..e15985b 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index f430e41..fd455aa 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -297,9 +297,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v2 06/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index a03c3ef..3d4b564 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -43,24 +43,28 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
  * The implementation uses gcc's reluctance to create a negative array, but
  * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * to inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error pre-gcc-4.4) and then call an undefined
+ * function with the error attribute (should always creates an error 4.3+).  If
+ * for some reason, neither creates a compile-time error, we'll still have a
+ * link-time error, which is harder to track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		if (condition)						\
+			__build_bug_on_failed();			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v2 07/10] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
(0), resulting in exactly one compile-time error on all versions of gcc.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    4 ++--
 include/linux/compiler.h |    5 +++++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 3d4b564..f8eae31 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -56,13 +56,13 @@ struct pt_regs;
  * link-time error, which is harder to track down.
  */
 #ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
 #define BUILD_BUG_ON(condition)						\
 	do {								\
 		extern void __build_bug_on_failed(void)			\
 			__compiletime_error("BUILD_BUG_ON failed");	\
-		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		__compiletime_error_fallback(condition);		\
 		if (condition)						\
 			__build_bug_on_failed();			\
 	} while(0)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index fd455aa..88ba201 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -296,6 +296,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition) \
+	 ((void)sizeof(char[1 - 2*!!(condition)]))
+#endif
+#ifndef __compiletime_error_fallback
+# define __compiletime_error_fallback(condition) (void)(0)
 #endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
-- 
1.7.3.4

[PATCH v2 08/10] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, BUILD_BUG_ON was evaluating to nothing in this case, and we
want (0) since this is a function-like macro that will be followed by a
semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index f8eae31..1b43ea2 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,7 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.3.4

[PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}

[danielfsantos]

Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
turned enabled), except that it allows you to specify the error message
you want emitted as the third parameter.  Under the hood, this relies on
BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
identical to BUILD_BUG_ON.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 1b43ea2..91bd9d5 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,6 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -38,6 +39,31 @@ struct pt_regs;
  */
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
+#define _CONCAT1(a, b) a##b
+#define CONCAT(a, b) _CONCAT1(a, b)
+#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
+
+#define BUILD_BUG_INTERNAL2(condition, msg, fn)			\
+	do {							\
+		extern void fn (void) __compiletime_error(msg);	\
+		__compiletime_error_fallback(condition);	\
+		if (condition)					\
+			fn();					\
+	} while (0)
+
+#define BUILD_BUG_INTERNAL(condition, msg, fn) \
+	BUILD_BUG_INTERNAL2(condition, msg, fn)
+
+/**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) \
+	BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))
+
 /**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
-- 
1.7.3.4

[PATCH v2 10/10] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[danielfsantos]

Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
also prevents the possibility of code being changed for one macro and
not for the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   17 +++--------------
 1 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 91bd9d5..ee880e5 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -84,14 +84,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		__compiletime_error_fallback(condition);		\
-		if (condition)						\
-			__build_bug_on_failed();			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -101,12 +95,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
-- 
1.7.3.4

Re: [PATCH v2 0/10] Cleanup & new features for compiler*.h and bug.h

[Steven Rostedt]

On Fri, 2012-10-05 at 14:35 -0500, danielfsantos@att.net wrote:
> This patch set is a dependency of the generic red-black tree patch set, which
> I have now split up into three smaller sets.
> 
> The major aim of this patch set is to cleanup compiler-gcc*.h and improve the
> manageability of of compiler features at various versions (when they are
> broken, etc.), and to cleanup & add some needed features to bug.h.
> 

A quick review of the patches look fine to me.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}

[Borislav Petkov]

On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@att.net wrote:
> Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
> turned enabled), except that it allows you to specify the error message
> you want emitted as the third parameter.  Under the hood, this relies on
> BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
> identical to BUILD_BUG_ON.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |   26 ++++++++++++++++++++++++++
>  1 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 1b43ea2..91bd9d5 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -16,6 +16,7 @@ struct pt_regs;
>  #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
>  #define BUILD_BUG_ON_ZERO(e) (0)
>  #define BUILD_BUG_ON_NULL(e) ((void*)0)
> +#define BUILD_BUG_ON_MSG(cond, msg) (0)
>  #define BUILD_BUG_ON(condition) (0)
>  #define BUILD_BUG() (0)
>  #else /* __CHECKER__ */
> @@ -38,6 +39,31 @@ struct pt_regs;
>   */
>  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
>  
> +#define _CONCAT1(a, b) a##b
> +#define CONCAT(a, b) _CONCAT1(a, b)

Let's call the indirection _CONCAT without the "1".

> +#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> +
> +#define BUILD_BUG_INTERNAL2(condition, msg, fn)			\
> +	do {							\
> +		extern void fn (void) __compiletime_error(msg);	\
> +		__compiletime_error_fallback(condition);	\
> +		if (condition)					\
> +			fn();					\
> +	} while (0)
> +
> +#define BUILD_BUG_INTERNAL(condition, msg, fn) \
> +	BUILD_BUG_INTERNAL2(condition, msg, fn)

Ditto. BUILD_BUG_INTERNAL2 should be __BUILD_BUG_INTERNAL and the one
calling it _BUILD_BUG_INTERNAL (with one underscore).

> +
> +/**
> + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> + * 		      error message.
> + * @condition: the condition which the compiler should know is false.
> + *
> + * See BUILD_BUG_ON for description.
> + */
> +#define BUILD_BUG_ON_MSG(cond, msg) \
> +	BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))

Btw, why are we adding the line at all? It is issued by gcc anyway:

cc -Wall    macros.c   -o macros
macros.c: In function ‘main’:
macros.c:22:1: error: ‘__build_bug_on_failed_22’ undeclared (first use in this function)
	^^^^

It is in front of the filename here.

macros.c:22:1: note: each undeclared identifier is reported only once for each function it appears in
make: *** [macros] Error 1

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v2 07/10] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Josh Triplett]

On Fri, Oct 05, 2012 at 02:42:46PM -0500, danielfsantos@att.net wrote:
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -296,6 +296,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>  #endif
>  #ifndef __compiletime_error
>  # define __compiletime_error(message)
> +# define __compiletime_error_fallback(condition) \
> +	 ((void)sizeof(char[1 - 2*!!(condition)]))
> +#endif
> +#ifndef __compiletime_error_fallback
> +# define __compiletime_error_fallback(condition) (void)(0)

Might want to use do { } while (0) here, to force the use of a
semicolon and avoid the use of __compiletime_error_fallback in an
expression.

- Josh Triplett

Re: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}

[Josh Triplett]

On Fri, Oct 05, 2012 at 10:58:58PM +0200, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@att.net wrote:
> > Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
> > turned enabled), except that it allows you to specify the error message
> > you want emitted as the third parameter.  Under the hood, this relies on
> > BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
> > identical to BUILD_BUG_ON.
> > 
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > ---
> >  include/linux/bug.h |   26 ++++++++++++++++++++++++++
> >  1 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index 1b43ea2..91bd9d5 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -16,6 +16,7 @@ struct pt_regs;
> >  #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
> >  #define BUILD_BUG_ON_ZERO(e) (0)
> >  #define BUILD_BUG_ON_NULL(e) ((void*)0)
> > +#define BUILD_BUG_ON_MSG(cond, msg) (0)
> >  #define BUILD_BUG_ON(condition) (0)
> >  #define BUILD_BUG() (0)
> >  #else /* __CHECKER__ */
> > @@ -38,6 +39,31 @@ struct pt_regs;
> >   */
> >  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
> >  
> > +#define _CONCAT1(a, b) a##b
> > +#define CONCAT(a, b) _CONCAT1(a, b)
> 
> Let's call the indirection _CONCAT without the "1".
> 
> > +#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> > +
> > +#define BUILD_BUG_INTERNAL2(condition, msg, fn)			\
> > +	do {							\
> > +		extern void fn (void) __compiletime_error(msg);	\
> > +		__compiletime_error_fallback(condition);	\
> > +		if (condition)					\
> > +			fn();					\
> > +	} while (0)
> > +
> > +#define BUILD_BUG_INTERNAL(condition, msg, fn) \
> > +	BUILD_BUG_INTERNAL2(condition, msg, fn)
> 
> Ditto. BUILD_BUG_INTERNAL2 should be __BUILD_BUG_INTERNAL and the one
> calling it _BUILD_BUG_INTERNAL (with one underscore).

Also, you don't need both the BUILD_BUG_INTERNAL and CONCAT/UNIQUIFY
macros.  My original implementation just used the BUILD_BUG_INTERNAL
family of macros; if you'd rather rename them, by all means do so, but I
don't think you need two separate families of multiply-indirect macros.

> > +
> > +/**
> > + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> > + * 		      error message.
> > + * @condition: the condition which the compiler should know is false.
> > + *
> > + * See BUILD_BUG_ON for description.
> > + */
> > +#define BUILD_BUG_ON_MSG(cond, msg) \
> > +	BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))
> 
> Btw, why are we adding the line at all? It is issued by gcc anyway:
> 
> cc -Wall    macros.c   -o macros
> macros.c: In function ‘main’:
> macros.c:22:1: error: ‘__build_bug_on_failed_22’ undeclared (first use in this function)

Because without that, you end up writing multiple prototypes for the
same function (__build_bug_on_failed) with different error attributes,
and GCC will ignore all but the last error attribute it sees, even with
a scoped prototype.

- Josh Triplett

Re: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}

[Steven Rostedt]

On Fri, 2012-10-05 at 22:58 +0200, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@att.net wrote:
> > Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
> > turned enabled), except that it allows you to specify the error message
> > you want emitted as the third parameter.  Under the hood, this relies on
> > BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
> > identical to BUILD_BUG_ON.
> > 
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > ---
> >  include/linux/bug.h |   26 ++++++++++++++++++++++++++
> >  1 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index 1b43ea2..91bd9d5 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -16,6 +16,7 @@ struct pt_regs;
> >  #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
> >  #define BUILD_BUG_ON_ZERO(e) (0)
> >  #define BUILD_BUG_ON_NULL(e) ((void*)0)
> > +#define BUILD_BUG_ON_MSG(cond, msg) (0)
> >  #define BUILD_BUG_ON(condition) (0)
> >  #define BUILD_BUG() (0)
> >  #else /* __CHECKER__ */
> > @@ -38,6 +39,31 @@ struct pt_regs;
> >   */
> >  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
> >  
> > +#define _CONCAT1(a, b) a##b
> > +#define CONCAT(a, b) _CONCAT1(a, b)
> 
> Let's call the indirection _CONCAT without the "1".

You're stricter than I ;-)

> 
> > +#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> > +
> > +#define BUILD_BUG_INTERNAL2(condition, msg, fn)			\
> > +	do {							\
> > +		extern void fn (void) __compiletime_error(msg);	\
> > +		__compiletime_error_fallback(condition);	\
> > +		if (condition)					\
> > +			fn();					\
> > +	} while (0)
> > +
> > +#define BUILD_BUG_INTERNAL(condition, msg, fn) \
> > +	BUILD_BUG_INTERNAL2(condition, msg, fn)
> 
> Ditto. BUILD_BUG_INTERNAL2 should be __BUILD_BUG_INTERNAL and the one
> calling it _BUILD_BUG_INTERNAL (with one underscore).

I thought about commenting about the '2' too, but figured it's only used
internally by BUILD_BUG_INTERNAL and was really not too concerned about
such a trivial thing. It could have been 42 for all I care ;-)

> 
> > +
> > +/**
> > + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> > + * 		      error message.
> > + * @condition: the condition which the compiler should know is false.
> > + *
> > + * See BUILD_BUG_ON for description.
> > + */
> > +#define BUILD_BUG_ON_MSG(cond, msg) \
> > +	BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))
> 
> Btw, why are we adding the line at all? It is issued by gcc anyway:
> 
> cc -Wall    macros.c   -o macros
> macros.c: In function ‘main’:
> macros.c:22:1: error: ‘__build_bug_on_failed_22’ undeclared (first use in this function)
> 	^^^^
> 
> It is in front of the filename here.
> 
> macros.c:22:1: note: each undeclared identifier is reported only once for each function it appears in
> make: *** [macros] Error 1

I was thinking that the number was added as a safety measure that the
line number would be shown for all versions of the compiler. I'm not
sure it is.

-- Steve

Re: [PATCH v2 07/10] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Daniel Santos]

On 10/05/2012 03:59 PM, Josh Triplett wrote:
> On Fri, Oct 05, 2012 at 02:42:46PM -0500, danielfsantos@att.net wrote:
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -296,6 +296,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>>  #endif
>>  #ifndef __compiletime_error
>>  # define __compiletime_error(message)
>> +# define __compiletime_error_fallback(condition) \
>> +	 ((void)sizeof(char[1 - 2*!!(condition)]))
>> +#endif
>> +#ifndef __compiletime_error_fallback
>> +# define __compiletime_error_fallback(condition) (void)(0)
>
> Might want to use do { } while (0) here, to force the use of a
> semicolon and avoid the use of __compiletime_error_fallback in an
> expression.
Sure!  But while we're here, we may want to consider a few other macros
in bug.h.  These two are intended to be used as an expression:

#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))

They are using a different technique to generate the compile-time error,
perhaps because the negative sized array wasn't always working past gcc
4.4? Either way, perhaps these can become

#define BUILD_BUG_ON_ZERO(e) ({BUILD_BUG_ON(e); 0;})
#define BUILD_BUG_ON_NULL(e) ({BUILD_BUG_ON(e); (void*)0;})

This would again give us our cute error message.  However, I don't know
when this style of expression began to be supported (I know it's a gcc
extension), but I'm guessing it's pre gcc 3.2 because it's used in
kernel.h.  Also:

#define BUILD_BUG_ON_NOT_POWER_OF_2(n)            \
        BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))

can become:

#define BUILD_BUG_ON_NOT_POWER_OF_2(n)                         \
        BUILD_BUG_ON_MSG((n) == 0 || (((n) & ((n) - 1)) != 0), \
                         #n " not a power of two")

I think the only thing that would leave unfinished is the __OPTIMIZE__ check
in the BUILD_BUG_ON definition.  This is a throw-back to the days before
BUILD_BUG_ON_NON_CONST (oops, that's still in another patch set).  Well, if
you look at version 1 of this patch set, you'll see that it has that check,
since __builtin_constant_p never returns one in an unoptimized build.
However, that's a bit more work because we will need to examine every use of
BUILD_BUG_ON and __builtin_constant_p.  I only found 2-3 last time I looked,
one of which was commented outwith the remark that it "breaks in funny
ways",
which we certainly already know about __builtin_constant_p.  Another was a
pretty complicated expression, but I'll have to look them up again.

Please let me know what you think.

Daniel

Re: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}

[Daniel Santos]

On 10/05/2012 04:02 PM, Josh Triplett wrote:
> On Fri, Oct 05, 2012 at 10:58:58PM +0200, Borislav Petkov wrote:
>> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@att.net wrote:
>>> Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
>>> turned enabled), except that it allows you to specify the error message
>>> you want emitted as the third parameter.  Under the hood, this relies on
>>> BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
>>> identical to BUILD_BUG_ON.
>>>
>>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>>> ---
>>>  include/linux/bug.h |   26 ++++++++++++++++++++++++++
>>>  1 files changed, 26 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>>> index 1b43ea2..91bd9d5 100644
>>> --- a/include/linux/bug.h
>>> +++ b/include/linux/bug.h
>>> @@ -16,6 +16,7 @@ struct pt_regs;
>>>  #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
>>>  #define BUILD_BUG_ON_ZERO(e) (0)
>>>  #define BUILD_BUG_ON_NULL(e) ((void*)0)
>>> +#define BUILD_BUG_ON_MSG(cond, msg) (0)
>>>  #define BUILD_BUG_ON(condition) (0)
>>>  #define BUILD_BUG() (0)
>>>  #else /* __CHECKER__ */
>>> @@ -38,6 +39,31 @@ struct pt_regs;
>>>   */
>>>  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
>>>  
>>> +#define _CONCAT1(a, b) a##b
>>> +#define CONCAT(a, b) _CONCAT1(a, b)
>>
>> Let's call the indirection _CONCAT without the "1".

No problem, naming conventions are good! :)

>>
>>> +#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
>>> +
>>> +#define BUILD_BUG_INTERNAL2(condition, msg, fn)			\
>>> +	do {							\
>>> +		extern void fn (void) __compiletime_error(msg);	\
>>> +		__compiletime_error_fallback(condition);	\
>>> +		if (condition)					\
>>> +			fn();					\
>>> +	} while (0)
>>> +
>>> +#define BUILD_BUG_INTERNAL(condition, msg, fn) \
>>> +	BUILD_BUG_INTERNAL2(condition, msg, fn)
>>
>> Ditto. BUILD_BUG_INTERNAL2 should be __BUILD_BUG_INTERNAL and the one
>> calling it _BUILD_BUG_INTERNAL (with one underscore).
>
> Also, you don't need both the BUILD_BUG_INTERNAL and CONCAT/UNIQUIFY
> macros.  My original implementation just used the BUILD_BUG_INTERNAL
> family of macros; if you'd rather rename them, by all means do so, but I
> don't think you need two separate families of multiply-indirect macros.

Yeah, I was thinking in terms of reusable macros.  I'm kinda thinking the
kernel needs a header just for handy little macros, like concat,
uniquify, the
IS_EMPTY and IF_EMPTY macros of mine in rbtree.h, etc.  There is a
stringify.h
that just contains a __stringify macro.  But here, it's just verbose, so
I'll
change it back to how you had it.

>>> +
>>> +/**
>>> + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
>>> + * 		      error message.
>>> + * @condition: the condition which the compiler should know is false.
>>> + *
>>> + * See BUILD_BUG_ON for description.
>>> + */
>>> +#define BUILD_BUG_ON_MSG(cond, msg) \
>>> +	BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))
>>
>> Btw, why are we adding the line at all? It is issued by gcc anyway:
>>
>> cc -Wall    macros.c   -o macros
>> macros.c: In function ‘main’:
>> macros.c:22:1: error: ‘__build_bug_on_failed_22’ undeclared (first use in this function)
>
> Because without that, you end up writing multiple prototypes for the
> same function (__build_bug_on_failed) with different error attributes,
> and GCC will ignore all but the last error attribute it sees, even with
> a scoped prototype.

Yeah, this is part of the trick to get non-existent functions with different
messages on their error attributes, so that each BUILD_BUG_ON-type macro can
have more helpful text in its error message.  I don't know what's in your
macros.c, but it should have given you a much more shiny error message.

Daniel

Re: [PATCH v2 01/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[Borislav Petkov]

On Fri, Oct 05, 2012 at 02:42:40PM -0500, danielfsantos@att.net wrote:
> This helps to keep the file from getting confusing, removes one
> duplicate version check and should encourage future editors to put new
> macros where they belong.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>
> ---
>  include/linux/compiler-gcc4.h |   20 +++++++++++---------
>  1 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 8721704..4506d65 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -13,6 +13,10 @@
>  #define __must_check 		__attribute__((warn_unused_result))
>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
>  
> +#if __GNUC_MINOR__ > 0
> +# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> +#endif
> +
>  #if __GNUC_MINOR__ >= 3
>  /* Mark functions as cold. gcc will assume any path leading to a call
>     to them will be unlikely.  This means a lot of manual unlikely()s
> @@ -31,6 +35,12 @@
>  
>  #define __linktime_error(message) __attribute__((__error__(message)))
>  
> +#ifndef __CHECKER__
> +# define __compiletime_warning(message) __attribute__((warning(message)))
> +# define __compiletime_error(message) __attribute__((error(message)))
> +#endif /* __CHECKER__ */
> +#endif /* __GNUC_MINOR__ >= 3 */
> +
>  #if __GNUC_MINOR__ >= 5
>  /*
>   * Mark a position in code as unreachable.  This can be used to
> @@ -46,8 +56,7 @@
>  /* Mark a function definition as prohibited from being cloned. */
>  #define __noclone	__attribute__((__noclone__))
>  
> -#endif
> -#endif
> +#endif /* __GNUC_MINOR__ >= 5 */
>  
>  #if __GNUC_MINOR__ >= 6
>  /*
> @@ -56,10 +65,3 @@
>  #define __visible __attribute__((externally_visible))
>  #endif
>  
> -#if __GNUC_MINOR__ > 0
> -#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> -#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)

This last hunk doesn't apply since mainline has a "4" above instead of
"3". And it has had a "4" since it got added by 4a3127693001c so unless
I'm missing something, how did the 3 appear in your patches?

> -#define __compiletime_warning(message) __attribute__((warning(message)))
> -#define __compiletime_error(message) __attribute__((error(message)))
> -#endif
> -- 
> 1.7.3.4

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v2 01/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[Daniel Santos]

On 10/06/2012 12:42 PM, Borislav Petkov wrote:
>> @@ -56,10 +65,3 @@
>>  #define __visible __attribute__((externally_visible))
>>  #endif
>>  
>> -#if __GNUC_MINOR__ > 0
>> -#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>> -#endif
>> -#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
>
> This last hunk doesn't apply since mainline has a "4" above instead of
> "3". And it has had a "4" since it got added by 4a3127693001c so unless
> I'm missing something, how did the 3 appear in your patches?
These are based against -mm, where another commit is already in that
changes it.  I was told that since that commit was already in -mm, to
not include it in the patch set:

6c620cf1536a0ce6a83ecaaaf05298dcc0f7d440 (committed 2012-09-27)

This was probably (at least partially) the result of the fiasco I had
with my email.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Borislav Petkov]

On Fri, Oct 05, 2012 at 02:42:42PM -0500, danielfsantos@att.net wrote:
> Using GCC_VERSION reduces complexity, is easier to read and is GCC's
> recommended mechanism for doing version checks. (Just don't ask me why
> they didn't define it in the first place.)  This also makes it easy to
> merge compiler-gcc{,3,4}.h should somebody want to.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>

Looks correct to me:

Acked-by: Borislav Petkov <bp@alien8.de>

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Borislav Petkov]

On Fri, Oct 05, 2012 at 02:42:42PM -0500, danielfsantos@att.net wrote:
> Using GCC_VERSION reduces complexity, is easier to read and is GCC's
> recommended mechanism for doing version checks. (Just don't ask me why
> they didn't define it in the first place.)  This also makes it easy to
> merge compiler-gcc{,3,4}.h should somebody want to.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>
> ---

[ … ]

> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 4506d65..bbfeb13 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -4,7 +4,7 @@
>  
>  /* GCC 4.1.[01] miscompiles __weak */
>  #ifdef __KERNEL__
> -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> +# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
>  //#  error Your version of gcc miscompiles the __weak directive

Did I miss something again? This "error" preprocessor function is
commented out here? Why?

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Daniel Santos]

On 10/06/2012 06:10 PM, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 02:42:42PM -0500, danielfsantos@att.net wrote:
>> Using GCC_VERSION reduces complexity, is easier to read and is GCC's
>> recommended mechanism for doing version checks. (Just don't ask me why
>> they didn't define it in the first place.)  This also makes it easy to
>> merge compiler-gcc{,3,4}.h should somebody want to.
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>> Acked-by: David Rientjes <rientjes@google.com>
>> ---
>
> [ … ]
>
>> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
>> index 4506d65..bbfeb13 100644
>> --- a/include/linux/compiler-gcc4.h
>> +++ b/include/linux/compiler-gcc4.h
>> @@ -4,7 +4,7 @@
>>  
>>  /* GCC 4.1.[01] miscompiles __weak */
>>  #ifdef __KERNEL__
>> -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
>> +# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
>>  //#  error Your version of gcc miscompiles the __weak directive
>
> Did I miss something again? This "error" preprocessor function is
> commented out here? Why?
We'll have to ask Andrew.  Maybe so he can test on those versions of gcc?

commit d3ffe64a1dbcfe18b57f90f7c01c40c93d0a8b92
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Fri Sep 28 00:02:42 2012 +0000

    a
   
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 934bc34..997fd8a 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -5,7 +5,7 @@
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
 # if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
-#  error Your version of gcc miscompiles the __weak directive
+//#  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif


I can provide you a version of these patches rebased against Linus if
you like, which I am using to test since the -mm & -next trees aren't
working on my machine (hardware, .config and/or LVM/RAID setup). I
haven't put Walken's patches underneath them however.

Re: [PATCH v2 0/10] Cleanup & new features for compiler*.h and bug.h

[Daniel Santos]

I just realized that in my patch set header I didn't specify that this
version of the patches is based against -mm.  However, I did not test
against -mm, I rebased them to mainline, merged some conflicts and made
some changes and tested there and I'm running that kernel now (that is,
with all of my patches, including fair scheduler using the generic
red-black tree).

This patch set builds fine against -mm & -next, but I just can't get
either of those to run correctly on my machine, even without my
patches.  (Sorry, that I don't have an actual test machine at the moment.)

On 10/05/2012 02:35 PM, danielfsantos@att.net wrote:
> This patch set is a dependency of the generic red-black tree patch set, which
> I have now split up into three smaller sets.
>
> The major aim of this patch set is to cleanup compiler-gcc*.h and improve the
> manageability of of compiler features at various versions (when they are
> broken, etc.), and to cleanup & add some needed features to bug.h.
>
> compiler-gcc*.h
> o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701)
> o Reorder all features based upon the version introduced (readability)
> o Change all version checks to use GCC_VERSION
> o Remove redundant __linktime_error
>
> bug.h
> o Improve BUILD_BUG_ON(expr) - Will now generate a compile-time error and in
>   gcc-4.4+, also emits an error message containing the expression that failed.
> o Add BUILD_BUG_ON_MSG(expr, msg) - Like BUILD_BUG_ON, except that you can
>   specify the error message that is emitted (again, gcc-4.4+).
> o Add BUILD_BUG_ON_INTERNAL(expr, fn, msg) - contains a generic implementation
>   of BUILG_BUG_ON{_MSG}.
> o Finally, the implementations of BUILD_BUG{,_ON,_ON_MSG} is consolidated,
>   eliminating duplicate code.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Borislav Petkov]

On Sun, Oct 07, 2012 at 01:27:58PM -0500, Daniel Santos wrote:
> > Did I miss something again? This "error" preprocessor function is
> > commented out here? Why?
> We'll have to ask Andrew.  Maybe so he can test on those versions of gcc?
> 
> commit d3ffe64a1dbcfe18b57f90f7c01c40c93d0a8b92
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date:   Fri Sep 28 00:02:42 2012 +0000
> 
>     a
>    
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 934bc34..997fd8a 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -5,7 +5,7 @@
>  /* GCC 4.1.[01] miscompiles __weak */
>  #ifdef __KERNEL__
>  # if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> -#  error Your version of gcc miscompiles the __weak directive
> +//#  error Your version of gcc miscompiles the __weak directive
>  # endif
>  #endif

Ah, interesting. I think akpm has been redoing -mm couple times recently
so you probably caught a temporary thing.

> I can provide you a version of these patches rebased against Linus if
> you like, which I am using to test since the -mm & -next trees aren't
> working on my machine (hardware, .config and/or LVM/RAID setup). I
> haven't put Walken's patches underneath them however.

Nah, not necessary. I'd simply wait after the merge window closes and
everything settles down and then crank out a patchset against one of
the major trees (say -mm, linus or -next) so we can agree on the final
versions. AFAICT, the general design is fine - it's just the details
that need to be hammered out with precision.

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Daniel Santos]

On 10/07/2012 02:42 PM, Borislav Petkov wrote:
> On Sun, Oct 07, 2012 at 01:27:58PM -0500, Daniel Santos wrote:
>>> Did I miss something again? This "error" preprocessor function is
>>> commented out here? Why?
>> We'll have to ask Andrew.  Maybe so he can test on those versions of gcc?
>>
>> commit d3ffe64a1dbcfe18b57f90f7c01c40c93d0a8b92
>> Author: Andrew Morton <akpm@linux-foundation.org>
>> Date:   Fri Sep 28 00:02:42 2012 +0000
>>
>>     a
>>    
>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>
>> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
>> index 934bc34..997fd8a 100644
>> --- a/include/linux/compiler-gcc4.h
>> +++ b/include/linux/compiler-gcc4.h
>> @@ -5,7 +5,7 @@
>>  /* GCC 4.1.[01] miscompiles __weak */
>>  #ifdef __KERNEL__
>>  # if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
>> -#  error Your version of gcc miscompiles the __weak directive
>> +//#  error Your version of gcc miscompiles the __weak directive
>>  # endif
>>  #endif
>
> Ah, interesting. I think akpm has been redoing -mm couple times recently
> so you probably caught a temporary thing.

I was guessing something like that, but I figured he had a reason for
doing it so I didn't dare ask the master! :)

>
>> I can provide you a version of these patches rebased against Linus if
>> you like, which I am using to test since the -mm & -next trees aren't
>> working on my machine (hardware, .config and/or LVM/RAID setup). I
>> haven't put Walken's patches underneath them however.
>
> Nah, not necessary. I'd simply wait after the merge window closes and
> everything settles down and then crank out a patchset against one of
> the major trees (say -mm, linus or -next) so we can agree on the final
> versions. AFAICT, the general design is fine - it's just the details
> that need to be hammered out with precision.
>
> Thanks.
If I had more time & energy for this part, I would try to find all uses
of BUILD_BUG_ON with __builtin_const_p, remove the __OPTIMIZE__ check
from BUILD_BUG_ON, put my BUILD_BUG_ON_NON_CONST macros back into this
patch set and adjust any other code in the kernel to not fail
un-optimized.  Also, I would figure out the reason for this commented
out check (arch/powerpc/kvm/timing.h:52):

    /* The BUILD_BUG_ON below breaks in funny ways, commented out
     * for now ... -BenH
    BUILD_BUG_ON(!__builtin_constant_p(type));
    */

and correct it with the appropriate new macro.  However, one of my
biggest problems is staying on task, perhaps partially due to having
ADHD.  In fact, *this* project (the generic red-black trees) got started
when I was exploring the possibilities of running parts of Wine in the
kernel, when I was dismayed by the lack of genericity in the kernel's
red-black tree code, so it's actually a tangent! :)  Don't get me wrong,
I don't regret it.  It has been a marvelous adventure in the
possibilities of the C language on modern compilers.  But after I finish
this up, I plan on writing up a paper on the "C metaprogramming"
techniques I seem to have discovered and then getting back to my Wine
project.  There are many other nify compile-time tricks that I
discovered in the exploration process that I didn't need to use here,
but which are worth documenting.

So basically, I know that I need to try to get this thing wrapped up.

Daniel

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Andrew Morton]

On Sun, 07 Oct 2012 13:27:58 -0500
Daniel Santos <danielfsantos@att.net> wrote:

> We'll have to ask Andrew.  Maybe so he can test on those versions of gcc?
> 
> commit d3ffe64a1dbcfe18b57f90f7c01c40c93d0a8b92
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date:   Fri Sep 28 00:02:42 2012 +0000
> 
>     a
>    
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 934bc34..997fd8a 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -5,7 +5,7 @@
>  /* GCC 4.1.[01] miscompiles __weak */
>  #ifdef __KERNEL__
>  # if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> -#  error Your version of gcc miscompiles the __weak directive
> +//#  error Your version of gcc miscompiles the __weak directive

hm, yeah, sorry, I use various old crufty cross-compilers.

There are quite a number of patches in -mm which aren't included in
linux-next and that's one of them.  The
NEXT_PATCHES_START/NEXT_PATCHES_END markers in the series file identify
the patches which Stephen selects.

Re: [PATCH v2 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Josh Triplett]

On Tue, Oct 09, 2012 at 11:41:58AM -0700, Andrew Morton wrote:
> On Sun, 07 Oct 2012 13:27:58 -0500
> Daniel Santos <danielfsantos@att.net> wrote:
> 
> > We'll have to ask Andrew.  Maybe so he can test on those versions of gcc?
> > 
> > commit d3ffe64a1dbcfe18b57f90f7c01c40c93d0a8b92
> > Author: Andrew Morton <akpm@linux-foundation.org>
> > Date:   Fri Sep 28 00:02:42 2012 +0000
> > 
> >     a
> >    
> >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > 
> > diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> > index 934bc34..997fd8a 100644
> > --- a/include/linux/compiler-gcc4.h
> > +++ b/include/linux/compiler-gcc4.h
> > @@ -5,7 +5,7 @@
> >  /* GCC 4.1.[01] miscompiles __weak */
> >  #ifdef __KERNEL__
> >  # if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> > -#  error Your version of gcc miscompiles the __weak directive
> > +//#  error Your version of gcc miscompiles the __weak directive
> 
> hm, yeah, sorry, I use various old crufty cross-compilers.

Ah, for build testing where you don't actually care if the resulting
kernel runs?

- Josh Triplett

Re: [PATCH 1/10] compiler-gcc4.h: correct verion check for __compiletime_error

[Michal Marek]

On Tue, Oct 02, 2012 at 11:25:12PM -0700, David Rientjes wrote:
> On Fri, 28 Sep 2012, Daniel Santos wrote:
> 
> > NOTE: this is has already been comitted to -mm
> > 
> > __attribute__((error(msg))) was introduced in gcc 4.3 (not 4.4) and as I
> > was unable to find any gcc bugs pertaining to it, I'm presuming that it
> > has functioned as advertised since 4.3.0.
> > 
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > Cc: Michal Marek <mmarek@suse.cz>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
> Tested-by: David Rientjes <rientjes@google.com>
> 
> Works with 4.3.6.

Applied to kbuild.git#kbuild now.

Michal

Re: [PATCH v2 01/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[David Rientjes]

On Sat, 6 Oct 2012, Daniel Santos wrote:

> These are based against -mm, where another commit is already in that
> changes it.  I was told that since that commit was already in -mm, to
> not include it in the patch set:
> 
> 6c620cf1536a0ce6a83ecaaaf05298dcc0f7d440 (committed 2012-09-27)
> 
> This was probably (at least partially) the result of the fiasco I had
> with my email.
> 

Yeah, this patch applies fine on linux-next, which is the correct thing to 
do if you're building upon already queued patches.

[PATCH v3 0/10] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets and is based off of linux-next.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve
the manageability of of compiler features at various versions (when they
are broken, etc.), add some needed features to bug.h and clean that up as
well.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701)
o Reorder all features based upon the version introduced (readability)
o Change all version checks to use GCC_VERSION
o Remove redundant __linktime_error

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Remove duplicate error messages in some cases.
o Introduce BUILD_BUG_ON_MSG and clean up the implementations of the
  BUILD_BUG* macros.

[PATCH v3 01/10] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 412bc6c..8914293 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH v3 02/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH v3 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8914293..9755029 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH v3 04/10] bug.h: directly include linux/compiler.h

[danielfsantos]

Currently, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason. (Later
patches will in this set use more macros defined in compiler*.h.)

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..4bd74d8 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
-- 
1.7.3.4

[PATCH v3 05/10] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 4bd74d8..a03c3ef 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -74,7 +74,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 9755029..7f143ac 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b121554..cbf6d9d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -299,9 +299,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v3 06/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index a03c3ef..3d4b564 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -43,24 +43,28 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
  * The implementation uses gcc's reluctance to create a negative array, but
  * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * to inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error pre-gcc-4.4) and then call an undefined
+ * function with the error attribute (should always creates an error 4.3+).  If
+ * for some reason, neither creates a compile-time error, we'll still have a
+ * link-time error, which is harder to track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		if (condition)						\
+			__build_bug_on_failed();			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v3 07/10] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    4 ++--
 include/linux/compiler.h |    7 +++++++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 3d4b564..f8eae31 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -56,13 +56,13 @@ struct pt_regs;
  * link-time error, which is harder to track down.
  */
 #ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
 #define BUILD_BUG_ON(condition)						\
 	do {								\
 		extern void __build_bug_on_failed(void)			\
 			__compiletime_error("BUILD_BUG_ON failed");	\
-		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		__compiletime_error_fallback(condition);		\
 		if (condition)						\
 			__build_bug_on_failed();			\
 	} while(0)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cbf6d9d..84926f2 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -298,6 +298,13 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition)		\
+	do {							\
+		((void)sizeof(char[1 - 2*!!(condition)]));	\
+	} while (0)
+#endif
+#ifndef __compiletime_error_fallback
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
-- 
1.7.3.4

[PATCH v3 08/10] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, BUILD_BUG_ON was evaluating to nothing in this case, and we
want (0) since this is a function-like macro that will be followed by a
semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index f8eae31..1b43ea2 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,7 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.3.4

[PATCH v3 09/10] bug.h: Add BUILD_BUG_ON_MSG & _BUILD_BUG_INTERNAL

[danielfsantos]

Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
enabled), except that it allows you to specify the error message you
want emitted as the third parameter.  Under the hood, this relies on
_BUILD_BUG_INTERNAL, which does the actual work and is pretty-much
identical to BUILD_BUG_ON.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 1b43ea2..f6f81f6 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,6 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -38,6 +39,27 @@ struct pt_regs;
  */
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
+#define __BUILD_BUG_INTERNAL(condition, msg, line)		\
+	do {							\
+		extern void __build_bug_on_failed_ ## line	\
+			(void) __compiletime_error(msg);	\
+		__compiletime_error_fallback(condition);	\
+		if (condition)					\
+			__build_bug_on_failed_ ## line();	\
+	} while (0)
+
+#define _BUILD_BUG_INTERNAL(condition, msg, line) \
+	__BUILD_BUG_INTERNAL(condition, msg, line)
+
+/**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) _BUILD_BUG_INTERNAL(cond, msg, __LINE__)
+
 /**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
-- 
1.7.3.4

[PATCH v3 10/10] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[danielfsantos]

Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
also prevents the possibility of code being changed for one macro and
not for the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   17 +++--------------
 1 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index f6f81f6..c791d2a 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -80,14 +80,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		__compiletime_error_fallback(condition);		\
-		if (condition)						\
-			__build_bug_on_failed();			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -97,12 +91,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
-- 
1.7.3.4

Re: [PATCH v3 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Borislav Petkov]

On Wed, Oct 24, 2012 at 11:33:54AM -0500, danielfsantos@att.net wrote:
> Using GCC_VERSION reduces complexity, is easier to read and is GCC's
> recommended mechanism for doing version checks. (Just don't ask me why
> they didn't define it in the first place.)  This also makes it easy to
> merge compiler-gcc{,3,4}.h should somebody want to.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>
> ---
>  include/linux/compiler-gcc3.h |    8 ++++----
>  include/linux/compiler-gcc4.h |   14 +++++++-------
>  2 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
> index 37d4124..7d89feb 100644
> --- a/include/linux/compiler-gcc3.h
> +++ b/include/linux/compiler-gcc3.h
> @@ -2,22 +2,22 @@
>  #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
>  #endif
>  
> -#if __GNUC_MINOR__ < 2
> +#if GCC_VERSION < 30200
>  # error Sorry, your compiler is too old - please upgrade it.
>  #endif
>  
> -#if __GNUC_MINOR__ >= 3
> +#if GCC_VERSION >= 30300
>  # define __used			__attribute__((__used__))
>  #else
>  # define __used			__attribute__((__unused__))
>  #endif
>  
> -#if __GNUC_MINOR__ >= 4
> +#if GCC_VERSION >= 30400
>  #define __must_check		__attribute__((warn_unused_result))
>  #endif
>  
>  #ifdef CONFIG_GCOV_KERNEL
> -# if __GNUC_MINOR__ < 4
> +# if GCC_VERSION < 30400
>  #   error "GCOV profiling support for gcc versions below 3.4 not included"
>  # endif /* __GNUC_MINOR__ */
>  #endif /* CONFIG_GCOV_KERNEL */
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 8914293..9755029 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -4,7 +4,7 @@
>  
>  /* GCC 4.1.[01] miscompiles __weak */
>  #ifdef __KERNEL__
> -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> +# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
>  #  error Your version of gcc miscompiles the __weak directive
>  # endif
>  #endif
> @@ -13,11 +13,11 @@
>  #define __must_check 		__attribute__((warn_unused_result))
>  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
>  
> -#if __GNUC_MINOR__ > 0
> +#if GCC_VERSION >= 40100

I can't seem to recall so did we explain already why ">= 40100" instead
of "> 40000"?

I mean, it is the same, but still...

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v3 04/10] bug.h: directly include linux/compiler.h

[Borislav Petkov]

On Wed, Oct 24, 2012 at 11:33:55AM -0500, danielfsantos@att.net wrote:
> Currently, we are only including asm/bug.h and then expecting that
> linux/compiler.h will eventually be included to define __linktime_error
> (used in BUILD_BUG_ON). This patch includes it directly for clarity and
> to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
> changed or not including linux/compiler.h for some reason. (Later
> patches will in this set use more macros defined in compiler*.h.)
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index aaac4bb..4bd74d8 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -2,6 +2,7 @@
>  #define _LINUX_BUG_H
>  
>  #include <asm/bug.h>
> +#include <linux/compiler.h>
>  
>  enum bug_trap_type {
>  	BUG_TRAP_TYPE_NONE = 0,
> -- 
> 1.7.3.4

Why is this a separate patch and why not add that single line in 6/10
where you define BUILD_BUG_ON?

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v3 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Josh Triplett]

On Wed, Oct 24, 2012 at 09:05:46PM +0200, Borislav Petkov wrote:
> On Wed, Oct 24, 2012 at 11:33:54AM -0500, danielfsantos@att.net wrote:
> > Using GCC_VERSION reduces complexity, is easier to read and is GCC's
> > recommended mechanism for doing version checks. (Just don't ask me why
> > they didn't define it in the first place.)  This also makes it easy to
> > merge compiler-gcc{,3,4}.h should somebody want to.
> > 
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > Acked-by: David Rientjes <rientjes@google.com>
> > ---
> >  include/linux/compiler-gcc3.h |    8 ++++----
> >  include/linux/compiler-gcc4.h |   14 +++++++-------
> >  2 files changed, 11 insertions(+), 11 deletions(-)
> > 
> > diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
> > index 37d4124..7d89feb 100644
> > --- a/include/linux/compiler-gcc3.h
> > +++ b/include/linux/compiler-gcc3.h
> > @@ -2,22 +2,22 @@
> >  #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
> >  #endif
> >  
> > -#if __GNUC_MINOR__ < 2
> > +#if GCC_VERSION < 30200
> >  # error Sorry, your compiler is too old - please upgrade it.
> >  #endif
> >  
> > -#if __GNUC_MINOR__ >= 3
> > +#if GCC_VERSION >= 30300
> >  # define __used			__attribute__((__used__))
> >  #else
> >  # define __used			__attribute__((__unused__))
> >  #endif
> >  
> > -#if __GNUC_MINOR__ >= 4
> > +#if GCC_VERSION >= 30400
> >  #define __must_check		__attribute__((warn_unused_result))
> >  #endif
> >  
> >  #ifdef CONFIG_GCOV_KERNEL
> > -# if __GNUC_MINOR__ < 4
> > +# if GCC_VERSION < 30400
> >  #   error "GCOV profiling support for gcc versions below 3.4 not included"
> >  # endif /* __GNUC_MINOR__ */
> >  #endif /* CONFIG_GCOV_KERNEL */
> > diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> > index 8914293..9755029 100644
> > --- a/include/linux/compiler-gcc4.h
> > +++ b/include/linux/compiler-gcc4.h
> > @@ -4,7 +4,7 @@
> >  
> >  /* GCC 4.1.[01] miscompiles __weak */
> >  #ifdef __KERNEL__
> > -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> > +# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
> >  #  error Your version of gcc miscompiles the __weak directive
> >  # endif
> >  #endif
> > @@ -13,11 +13,11 @@
> >  #define __must_check 		__attribute__((warn_unused_result))
> >  #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
> >  
> > -#if __GNUC_MINOR__ > 0
> > +#if GCC_VERSION >= 40100
> 
> I can't seem to recall so did we explain already why ">= 40100" instead
> of "> 40000"?
> 
> I mean, it is the same, but still...

__GNUC_MINOR__ > 0 means __GNUC_MINOR__ >= 1, so that would allow 4.1 or
newer.  However, GCC_VERSION > 40000 would also allow 4.0.n for n > 0.

- Josh Triplett

Re: [PATCH v3 03/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[Borislav Petkov]

On Wed, Oct 24, 2012 at 02:49:00PM -0700, Josh Triplett wrote:
> > I can't seem to recall so did we explain already why ">= 40100" instead
> > of "> 40000"?
> > 
> > I mean, it is the same, but still...
> 
> __GNUC_MINOR__ > 0 means __GNUC_MINOR__ >= 1, so that would allow 4.1 or
> newer.  However, GCC_VERSION > 40000 would also allow 4.0.n for n > 0.

Ah, sure. In that case

Acked-by: Borislav Petkov <bp@alien8.de>

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v3 05/10] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[Borislav Petkov]

On Wed, Oct 24, 2012 at 11:33:56AM -0500, danielfsantos@att.net wrote:
> __linktime_error() does the same thing as __compiletime_error() and is
> only used in bug.h.  Since the macro defines a function attribute that
> will cause a failure at compile-time (not link-time), it makes more
> sense to keep __compiletime_error(), which is also neatly mated with
> __compiletime_warning().
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v3 06/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Borislav Petkov]

On Wed, Oct 24, 2012 at 11:33:57AM -0500, danielfsantos@att.net wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will.  This patch modifies
> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> function attribute so that you don't have to build the entire kernel to
> discover that you have a problem, and then enjoy trying to track it down
> from a link-time error.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |   24 ++++++++++++++----------
>  1 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index a03c3ef..3d4b564 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -43,24 +43,28 @@ struct pt_regs;
>   * @condition: the condition which the compiler should know is false.
>   *
>   * If you have some code which relies on certain constants being equal, or
> - * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> + * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>   * detect if someone changes it.
>   *
>   * The implementation uses gcc's reluctance to create a negative array, but
>   * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
> - * to inline functions).  So as a fallback we use the optimizer; if it can't
> - * prove the condition is false, it will cause a link error on the undefined
> - * "__build_bug_on_failed".  This error message can be harder to track down
> - * though, hence the two different methods.
> + * to inline functions).  Luckily, in 4.3 they added the "error" function
> + * attribute just for this type of case.  Thus, we use a negative sized array
> + * (should always create an error pre-gcc-4.4) and then call an undefined

	.... always create an error on gcc versions older than 4.4)

> + * function with the error attribute (should always creates an error 4.3+).  If

					..... always create an error on gcc 4.3 and later)

> + * for some reason, neither creates a compile-time error, we'll still have a
> + * link-time error, which is harder to track down.
>   */
>  #ifndef __OPTIMIZE__
>  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>  #else
> -extern int __build_bug_on_failed;
> -#define BUILD_BUG_ON(condition)					\
> -	do {							\
> -		((void)sizeof(char[1 - 2*!!(condition)]));	\
> -		if (condition) __build_bug_on_failed = 1;	\
> +#define BUILD_BUG_ON(condition)						\
> +	do {								\
> +		extern void __build_bug_on_failed(void)			\
> +			__compiletime_error("BUILD_BUG_ON failed");	\
> +		((void)sizeof(char[1 - 2*!!(condition)]));		\
> +		if (condition)						\
> +			__build_bug_on_failed();			\
>  	} while(0)
>  #endif

With the changes above:

Acked-by: Borislav Petkov <bp@alien8.de>

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v3 04/10] bug.h: directly include linux/compiler.h

[Daniel Santos]

On 10/24/2012 02:55 PM, Borislav Petkov wrote:
> On Wed, Oct 24, 2012 at 11:33:55AM -0500, danielfsantos@att.net wrote:
>> Currently, we are only including asm/bug.h and then expecting that
>> linux/compiler.h will eventually be included to define __linktime_error
>> (used in BUILD_BUG_ON). This patch includes it directly for clarity and
>> to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
>> changed or not including linux/compiler.h for some reason. (Later
>> patches will in this set use more macros defined in compiler*.h.)
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>> ---
>>  include/linux/bug.h |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>> index aaac4bb..4bd74d8 100644
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -2,6 +2,7 @@
>>  #define _LINUX_BUG_H
>>  
>>  #include <asm/bug.h>
>> +#include <linux/compiler.h>
>>  
>>  enum bug_trap_type {
>>  	BUG_TRAP_TYPE_NONE = 0,
>> -- 
>> 1.7.3.4
> Why is this a separate patch and why not add that single line in 6/10
> where you define BUILD_BUG_ON?
>
> Thanks.
Sorry about that.  I think this was originally in another patch with
something else that I moved to another patch set and it ended up by its
self.  I'll squash it and resubmit.

[PATCH v4 0/10] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

 include/linux/bug.h           |   59 ++++++++++++++++++++++++++--------------
 include/linux/compiler-gcc.h  |    3 ++
 include/linux/compiler-gcc3.h |    8 +++---
 include/linux/compiler-gcc4.h |   28 +++++++++---------
 include/linux/compiler.h      |    8 ++++-
 5 files changed, 65 insertions(+), 41 deletions(-)

Changes in v4:
o Squash a minor commit (per Borislav Petkov)
o Change some comment text (per Borislav Petkov)
o Add some acks

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets and is based off of linux-next.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve
the manageability of of compiler features at various versions (when they
are broken, etc.), add some needed features to bug.h and clean that up as
well.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701)
o Reorder all features based upon the version introduced (readability)
o Change all version checks to use GCC_VERSION
o Remove redundant __linktime_error

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Remove duplicate error messages in some cases.
o Introduce BUILD_BUG_ON_MSG and clean up the implementations of the
  BUILD_BUG* macros.

[PATCH v4 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 412bc6c..8914293 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH v4 2/9] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH v4 3/9] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8914293..9755029 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH v4 4/9] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..298a916 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 9755029..7f143ac 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b121554..cbf6d9d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -299,9 +299,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v4 5/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Also, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |   30 ++++++++++++++++++------------
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 298a916..03259d7 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -42,24 +43,29 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
- * The implementation uses gcc's reluctance to create a negative array, but
- * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		if (condition)						\
+			__build_bug_on_failed();			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    4 ++--
 include/linux/compiler.h |    7 +++++++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 03259d7..da03dc1 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -57,13 +57,13 @@ struct pt_regs;
  * track down.
  */
 #ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
 #define BUILD_BUG_ON(condition)						\
 	do {								\
 		extern void __build_bug_on_failed(void)			\
 			__compiletime_error("BUILD_BUG_ON failed");	\
-		((void)sizeof(char[1 - 2*!!(condition)]));		\
+		__compiletime_error_fallback(condition);		\
 		if (condition)						\
 			__build_bug_on_failed();			\
 	} while(0)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cbf6d9d..84926f2 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -298,6 +298,13 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition)		\
+	do {							\
+		((void)sizeof(char[1 - 2*!!(condition)]));	\
+	} while (0)
+#endif
+#ifndef __compiletime_error_fallback
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
-- 
1.7.3.4

[PATCH v4 7/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, BUILD_BUG_ON was evaluating to nothing in this case, and we
want (0) since this is a function-like macro that will be followed by a
semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index da03dc1..6c38988 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,7 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.3.4

[PATCH v4 8/9] bug.h: Add BUILD_BUG_ON_MSG & _BUILD_BUG_INTERNAL

[danielfsantos]

Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
enabled), except that it allows you to specify the error message you
want emitted as the third parameter.  Under the hood, this relies on
_BUILD_BUG_INTERNAL, which does the actual work and is pretty-much
identical to BUILD_BUG_ON.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 6c38988..3bc1ddf 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,6 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -38,6 +39,27 @@ struct pt_regs;
  */
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
+#define __BUILD_BUG_INTERNAL(condition, msg, line)		\
+	do {							\
+		extern void __build_bug_on_failed_ ## line	\
+			(void) __compiletime_error(msg);	\
+		__compiletime_error_fallback(condition);	\
+		if (condition)					\
+			__build_bug_on_failed_ ## line();	\
+	} while (0)
+
+#define _BUILD_BUG_INTERNAL(condition, msg, line) \
+	__BUILD_BUG_INTERNAL(condition, msg, line)
+
+/**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) _BUILD_BUG_INTERNAL(cond, msg, __LINE__)
+
 /**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
-- 
1.7.3.4

[PATCH v4 9/9] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[danielfsantos]

Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
also prevents the possibility of code being changed for one macro and
not for the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |   17 +++--------------
 1 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 3bc1ddf..b58ba51 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -81,14 +81,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		__compiletime_error_fallback(condition);		\
-		if (condition)						\
-			__build_bug_on_failed();			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -98,12 +92,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
-- 
1.7.3.4

Re: [PATCH v4 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[Borislav Petkov]

On Sun, Oct 28, 2012 at 03:57:07PM -0500, danielfsantos@att.net wrote:
> This helps to keep the file from getting confusing, removes one
> duplicate version check and should encourage future editors to put new
> macros where they belong.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: David Rientjes <rientjes@google.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Borislav Petkov]

On Sun, Oct 28, 2012 at 03:57:12PM -0500, danielfsantos@att.net wrote:
> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
> creating compile-time errors required a little trickery.
> BUILD_BUG{,_ON} uses this attribute when available to generate
> compile-time errors, but also uses the negative-sized array trick for
> older compilers, resulting in two error messages in some cases.  The
> reason it's "some" cases is that as of gcc 4.4, the negative-sized array
> will not create an error in some situations, like inline functions.
> 
> This patch replaces the negative-sized array code with the new
> __compiletime_error_fallback() macro which expands to the same thing
> unless the the error attribute is available, in which case it expands to
> do{}while(0), resulting in exactly one compile-time error on all
> versions of gcc.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h      |    4 ++--
>  include/linux/compiler.h |    7 +++++++
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 03259d7..da03dc1 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -57,13 +57,13 @@ struct pt_regs;
>   * track down.
>   */
>  #ifndef __OPTIMIZE__
> -#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> +#define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
>  #else
>  #define BUILD_BUG_ON(condition)						\
>  	do {								\
>  		extern void __build_bug_on_failed(void)			\
>  			__compiletime_error("BUILD_BUG_ON failed");	\
> -		((void)sizeof(char[1 - 2*!!(condition)]));		\
> +		__compiletime_error_fallback(condition);		\
>  		if (condition)						\
>  			__build_bug_on_failed();			\

If we're defining a fallback, shouldn't it come second? I.e.:

		if (condition)
			__build_bug_on_failed();
		__compiletime_error_fallback(condition);

Also, the error message from __build_bug_on_failed is much more
informative:

arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
arch/x86/kernel/cpu/amd.c:486:2: error: call to ‘__build_bug_on_failed’ declared with attribute error: BUILD_BUG_ON failed
make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [arch/x86/kernel/cpu/] Error 2

than

arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
arch/x86/kernel/cpu/amd.c:486:2: error: size of unnamed array is negative
make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [arch/x86/kernel/cpu/] Error 2

Finally, you need to do:

	bool __cond = !!(condition);

and use __cond so that condition doesn't get evaluated multiple times
(possibly with side effects).

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 7/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[Borislav Petkov]

On Sun, Oct 28, 2012 at 03:57:13PM -0500, danielfsantos@att.net wrote:
> When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
> However, BUILD_BUG_ON was evaluating to nothing in this case, and we
> want (0) since this is a function-like macro that will be followed by a
> semicolon.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 8/9] bug.h: Add BUILD_BUG_ON_MSG & _BUILD_BUG_INTERNAL

[Borislav Petkov]

On Sun, Oct 28, 2012 at 03:57:14PM -0500, danielfsantos@att.net wrote:
> Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
> enabled), except that it allows you to specify the error message you
> want emitted as the third parameter.  Under the hood, this relies on
> _BUILD_BUG_INTERNAL, which does the actual work and is pretty-much
> identical to BUILD_BUG_ON.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 6c38988..3bc1ddf 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -16,6 +16,7 @@ struct pt_regs;
>  #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
>  #define BUILD_BUG_ON_ZERO(e) (0)
>  #define BUILD_BUG_ON_NULL(e) ((void*)0)
> +#define BUILD_BUG_ON_MSG(cond, msg) (0)
>  #define BUILD_BUG_ON(condition) (0)
>  #define BUILD_BUG() (0)
>  #else /* __CHECKER__ */
> @@ -38,6 +39,27 @@ struct pt_regs;
>   */
>  #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
>  
> +#define __BUILD_BUG_INTERNAL(condition, msg, line)		\
> +	do {							\
> +		extern void __build_bug_on_failed_ ## line	\
> +			(void) __compiletime_error(msg);	\
> +		__compiletime_error_fallback(condition);	\
> +		if (condition)					\
> +			__build_bug_on_failed_ ## line();	\
> +	} while (0)
> +
> +#define _BUILD_BUG_INTERNAL(condition, msg, line) \
> +	__BUILD_BUG_INTERNAL(condition, msg, line)

Stupid question:

can BUILD_BUG_ON and BUILD_BUG_ON_MSG both use __BUILD_BUG_INTERNAL?

In the BUILD_BUG_ON msg will be "BUILD_BUG_ON failed" and line empty.
Can that even work?

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 9/9] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[Borislav Petkov]

On Sun, Oct 28, 2012 at 03:57:15PM -0500, danielfsantos@att.net wrote:
> Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
> call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
> also prevents the possibility of code being changed for one macro and
> not for the other (which was previously the case for BUILD_BUG and
> BUILD_BUG_ON).
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |   17 +++--------------
>  1 files changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 3bc1ddf..b58ba51 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -81,14 +81,8 @@ struct pt_regs;
>  #ifndef __OPTIMIZE__
>  #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
>  #else
> -#define BUILD_BUG_ON(condition)						\
> -	do {								\
> -		extern void __build_bug_on_failed(void)			\
> -			__compiletime_error("BUILD_BUG_ON failed");	\
> -		__compiletime_error_fallback(condition);		\
> -		if (condition)						\
> -			__build_bug_on_failed();			\
> -	} while(0)
> +#define BUILD_BUG_ON(condition) \
> +	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)

Concatenating "condition" might not be very informative in all cases.
For example:

BUILD_BUG_ON(1);

Having __LINE__ is good enough IMHO.

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 8/9] bug.h: Add BUILD_BUG_ON_MSG & _BUILD_BUG_INTERNAL

[Borislav Petkov]

On Tue, Oct 30, 2012 at 06:17:47PM +0100, Borislav Petkov wrote:
> can BUILD_BUG_ON and BUILD_BUG_ON_MSG both use __BUILD_BUG_INTERNAL?
>
> In the BUILD_BUG_ON msg will be "BUILD_BUG_ON failed" and line empty.
> Can that even work?

Yes it can, I should simply look at patch 9/9 first :-).

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 9/9] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[Josh Triplett]

On Tue, Oct 30, 2012 at 08:19:05PM +0100, Borislav Petkov wrote:
> On Sun, Oct 28, 2012 at 03:57:15PM -0500, danielfsantos@att.net wrote:
> > Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
> > call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
> > also prevents the possibility of code being changed for one macro and
> > not for the other (which was previously the case for BUILD_BUG and
> > BUILD_BUG_ON).
> > 
> > Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> > ---
> >  include/linux/bug.h |   17 +++--------------
> >  1 files changed, 3 insertions(+), 14 deletions(-)
> > 
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index 3bc1ddf..b58ba51 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -81,14 +81,8 @@ struct pt_regs;
> >  #ifndef __OPTIMIZE__
> >  #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
> >  #else
> > -#define BUILD_BUG_ON(condition)						\
> > -	do {								\
> > -		extern void __build_bug_on_failed(void)			\
> > -			__compiletime_error("BUILD_BUG_ON failed");	\
> > -		__compiletime_error_fallback(condition);		\
> > -		if (condition)						\
> > -			__build_bug_on_failed();			\
> > -	} while(0)
> > +#define BUILD_BUG_ON(condition) \
> > +	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> 
> Concatenating "condition" might not be very informative in all cases.
> For example:
> 
> BUILD_BUG_ON(1);
> 
> Having __LINE__ is good enough IMHO.

While it doesn't always help, it may help sometimes.  Worst case,
BUILD_BUG_ON(1) gives you no less information than it did before; best
case, it gives you useful data.

- Josh Triplett

Re: [PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Daniel Santos]

On 10/30/2012 11:19 AM, Borislav Petkov wrote:
> On Sun, Oct 28, 2012 at 03:57:12PM -0500, danielfsantos@att.net wrote:
>> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
>> creating compile-time errors required a little trickery.
>> BUILD_BUG{,_ON} uses this attribute when available to generate
>> compile-time errors, but also uses the negative-sized array trick for
>> older compilers, resulting in two error messages in some cases.  The
>> reason it's "some" cases is that as of gcc 4.4, the negative-sized array
>> will not create an error in some situations, like inline functions.
>>
>> This patch replaces the negative-sized array code with the new
>> __compiletime_error_fallback() macro which expands to the same thing
>> unless the the error attribute is available, in which case it expands to
>> do{}while(0), resulting in exactly one compile-time error on all
>> versions of gcc.
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>> ---
>>  include/linux/bug.h      |    4 ++--
>>  include/linux/compiler.h |    7 +++++++
>>  2 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>> index 03259d7..da03dc1 100644
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -57,13 +57,13 @@ struct pt_regs;
>>   * track down.
>>   */
>>  #ifndef __OPTIMIZE__
>> -#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>> +#define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
>>  #else
>>  #define BUILD_BUG_ON(condition)						\
>>  	do {								\
>>  		extern void __build_bug_on_failed(void)			\
>>  			__compiletime_error("BUILD_BUG_ON failed");	\
>> -		((void)sizeof(char[1 - 2*!!(condition)]));		\
>> +		__compiletime_error_fallback(condition);		\
>>  		if (condition)						\
>>  			__build_bug_on_failed();			\
> If we're defining a fallback, shouldn't it come second? I.e.:
>
> 		if (condition)
> 			__build_bug_on_failed();
> 		__compiletime_error_fallback(condition);
>
> Also, the error message from __build_bug_on_failed is much more
> informative:
>
> arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
> arch/x86/kernel/cpu/amd.c:486:2: error: call to ‘__build_bug_on_failed’ declared with attribute error: BUILD_BUG_ON failed
> make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [arch/x86/kernel/cpu/] Error 2
>
> than
>
> arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
> arch/x86/kernel/cpu/amd.c:486:2: error: size of unnamed array is negative
> make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [arch/x86/kernel/cpu/] Error 2
Yes, the __build_bug_on_failed message is much more informative.  This
will only increase with these patches.  For example, the line

BUILD_BUG_ON(sizeof(*c) != 4);

emits this error:

arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
arch/x86/kernel/cpu/amd.c:486:2: error: call to
‘__build_bug_on_failed_486’ declared with attribute error: BUILD_BUG_ON
failed: sizeof(*c) != 4
make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
make: *** [arch/x86/kernel/cpu/amd.o] Error 2

It's true that there is some redundancy in there as well as the
gibberish line number embedded in the function name, but the end of the
line spits out the exact statement that failed.

But as far as rather the fallback is first or the __compiletime_error
function is a matter of asthetics, since it's really an either/or
situation.  Either the __build_bug_on_failedxxx function will be
declared with __attribute__((error(message))) and the fallback will
expand to a no-op, or the fallback will produce code that (presumably
always?) breaks the build.  For insurance, a link-time error will occur
if the fallback code fails to break the build.

Realistically, a single macro could be defined in compiler*.h that
encapsulates the entirety of this mechanism and only exposes a "black
box" macro, that will simply expand to something that breaks the build
in the most appropriate fashion based upon the version of gcc.  In
essence, the new BUILD_BUG_ON_MSG macro attempts to fill that roll.
>
> Finally, you need to do:
>
> 	bool __cond = !!(condition);
>
> and use __cond so that condition doesn't get evaluated multiple times
> (possibly with side effects).
>
> Thanks.
Big problem!  Very good catch, thank you!  All good programmers know not
use expressions that can have side effects in an assert-type macro, but
this it should certainly be as dummy proof as possible.  That will force
others to get a really *really* good dummy if they want to break it!

Thank you for this! I suppose another justification for having a single
"black box" macro that does this in one place and addresses all of these
tricky issues.

I guess I'll fix it up (and address the emails on the other patches) and
do a v5 then for the whole set? (is that the right way to resubmit with
these corrections?)

Thanks
Daniel

Re: [PATCH v4 9/9] bug.h: Convert BUILD_BUG{,_ON} to use BUILD_BUG_ON_MSG

[Daniel Santos]

On 10/30/2012 08:02 PM, Josh Triplett wrote:
> On Tue, Oct 30, 2012 at 08:19:05PM +0100, Borislav Petkov wrote:
>> On Sun, Oct 28, 2012 at 03:57:15PM -0500, danielfsantos@att.net wrote:
>>> Remove duplicate code by converting BUILD_BUG and BUILD_BUG_ON to just
>>> call BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but
>>> also prevents the possibility of code being changed for one macro and
>>> not for the other (which was previously the case for BUILD_BUG and
>>> BUILD_BUG_ON).
>>>
>>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>>> ---
>>>  include/linux/bug.h |   17 +++--------------
>>>  1 files changed, 3 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>>> index 3bc1ddf..b58ba51 100644
>>> --- a/include/linux/bug.h
>>> +++ b/include/linux/bug.h
>>> @@ -81,14 +81,8 @@ struct pt_regs;
>>>  #ifndef __OPTIMIZE__
>>>  #define BUILD_BUG_ON(condition) __compiletime_error_fallback(condition)
>>>  #else
>>> -#define BUILD_BUG_ON(condition)						\
>>> -	do {								\
>>> -		extern void __build_bug_on_failed(void)			\
>>> -			__compiletime_error("BUILD_BUG_ON failed");	\
>>> -		__compiletime_error_fallback(condition);		\
>>> -		if (condition)						\
>>> -			__build_bug_on_failed();			\
>>> -	} while(0)
>>> +#define BUILD_BUG_ON(condition) \
>>> +	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>> Concatenating "condition" might not be very informative in all cases.
>> For example:
>>
>> BUILD_BUG_ON(1);
>>
>> Having __LINE__ is good enough IMHO.

Honestly, __LINE__ is only used to keep the function name unique.  If
anything, I think that having it creates more confusion rather than adds
clarity since the error message will indicate the file and line number
anyway.  So in other words, it is redundant without it being apparent
why.  Of course, it's a very simple and portable mechanism to keep the
symbols unique.  IMO, using __COUNTER__would be better for clarity
(since the number wouldn't relate to the anything real), but it is not
portable across versions of gcc (introduced in 4.4 or some such), so we
are using __LINE__.

> While it doesn't always help, it may help sometimes.  Worst case,
> BUILD_BUG_ON(1) gives you no less information than it did before; best
> case, it gives you useful data.

Yeah, and depending upon what it's fed (and how much pre-processing had
been done on that) it can actually prove helpful because stringifying
condition can reveal pre-processing errors as well.  So if you passed
some macro as the condition and it didn't expand the way you expected,
this error message will print out exactly how it expanded, up to the
point of having been passed to BUILD_BUG_ON.  I don't know how much that
could potentially help, but for troubleshooting, I find extra
information helpful, more often than harmful.

Daniel

Re: [PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Borislav Petkov]

On Wed, Oct 31, 2012 at 12:34:45AM -0500, Daniel Santos wrote:
> Yes, the __build_bug_on_failed message is much more informative.  This
> will only increase with these patches.  For example, the line
> 
> BUILD_BUG_ON(sizeof(*c) != 4);
> 
> emits this error:
> 
> arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
> arch/x86/kernel/cpu/amd.c:486:2: error: call to
> ‘__build_bug_on_failed_486’ declared with attribute error: BUILD_BUG_ON
> failed: sizeof(*c) != 4
> make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
> make: *** [arch/x86/kernel/cpu/amd.o] Error 2
> 
> It's true that there is some redundancy in there as well as the
> gibberish line number embedded in the function name, but the end of the
> line spits out the exact statement that failed.

I guess that's as good as it gets. But it's fine IMO, it tells you
exactly what you need to know.

> But as far as rather the fallback is first or the __compiletime_error
> function is a matter of asthetics, since it's really an either/or
> situation.  Either the __build_bug_on_failedxxx function will be
> declared with __attribute__((error(message))) and the fallback will
> expand to a no-op, or the fallback will produce code that (presumably
> always?) breaks the build.  For insurance, a link-time error will occur
> if the fallback code fails to break the build.

Right, but my suggestion was to have the more informative message always
trigger first, if possible and if gcc supports it (practically, more
and more systems will be upgrading gcc which has the error attribute
with time) and have the less informative one be the more seldom one. The
"fallback" naming is just a minor issue.

This way, the error message would be precise on most modern toolchains.
Older toolchains will issue something about negative array size, which
is not really helpful so one would have to fire up an editor and
actually look at the code :).

> Realistically, a single macro could be defined in compiler*.h that
> encapsulates the entirety of this mechanism and only exposes a "black
> box" macro, that will simply expand to something that breaks the build
> in the most appropriate fashion based upon the version of gcc.  In
> essence, the new BUILD_BUG_ON_MSG macro attempts to fill that roll.

Yes.

> I guess I'll fix it up (and address the emails on the other patches)
> and do a v5 then for the whole set? (is that the right way to resubmit
> with these corrections?)

Well, you could wait a couple of days first to gather feedback from
other people and then resend. This way you give chance to people to take
a look without them seeing too many versions of the patchset and getting
confused.

What I always do is send out the patchset, collect and discuss changes,
add in the required changes and test it while the discussions go on.
After they settle down (and they do in a couple of days, in most cases)
I then send out the newly tested version out.

That whole exercise takes more or less a week if you're doing other
stuff in between :)

-- 
Regards/Gruss,
    Boris.

Re: [PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Daniel Santos]

On 10/31/2012 06:06 AM, Borislav Petkov wrote:
> On Wed, Oct 31, 2012 at 12:34:45AM -0500, Daniel Santos wrote:
>> Yes, the __build_bug_on_failed message is much more informative.  This
>> will only increase with these patches.  For example, the line
>>
>> BUILD_BUG_ON(sizeof(*c) != 4);
>>
>> emits this error:
>>
>> arch/x86/kernel/cpu/amd.c: In function ‘early_init_amd’:
>> arch/x86/kernel/cpu/amd.c:486:2: error: call to
>> ‘__build_bug_on_failed_486’ declared with attribute error: BUILD_BUG_ON
>> failed: sizeof(*c) != 4
>> make[1]: *** [arch/x86/kernel/cpu/amd.o] Error 1
>> make: *** [arch/x86/kernel/cpu/amd.o] Error 2
>>
>> It's true that there is some redundancy in there as well as the
>> gibberish line number embedded in the function name, but the end of the
>> line spits out the exact statement that failed.
> I guess that's as good as it gets. But it's fine IMO, it tells you
> exactly what you need to know.
Yeah, that's what I'm thinking as well.  Of course, I'm *always* happy
for somebody to come up with a superior solution! :)
>
>> But as far as rather the fallback is first or the __compiletime_error
>> function is a matter of asthetics, since it's really an either/or
>> situation.  Either the __build_bug_on_failedxxx function will be
>> declared with __attribute__((error(message))) and the fallback will
>> expand to a no-op, or the fallback will produce code that (presumably
>> always?) breaks the build.  For insurance, a link-time error will occur
>> if the fallback code fails to break the build.
> Right, but my suggestion was to have the more informative message always
> trigger first, if possible and if gcc supports it (practically, more
> and more systems will be upgrading gcc which has the error attribute
> with time) and have the less informative one be the more seldom one. The
> "fallback" naming is just a minor issue.
>
> This way, the error message would be precise on most modern toolchains.
> Older toolchains will issue something about negative array size, which
> is not really helpful so one would have to fire up an editor and
> actually look at the code :).

lol! :)  Yeah, this is exactly how it should be behaving at this point,
although it's not too clear with the "fallback" macro being defined
elsewhere that it's doing nothing when the error attribute is
available.  I suppose this is another reason to move the whole mechanism
to compiler*.h or add some comments to clarify what's going on.
>> Realistically, a single macro could be defined in compiler*.h that
>> encapsulates the entirety of this mechanism and only exposes a "black
>> box" macro, that will simply expand to something that breaks the build
>> in the most appropriate fashion based upon the version of gcc.  In
>> essence, the new BUILD_BUG_ON_MSG macro attempts to fill that roll.
> Yes.

Hmmm, this gets tricky.  So I think you are talking about a single
function-like macro that will create the built-time error.  As I see it,
we'll need to move the entirety of __BUILD_BUG_INTERNAL (with the double
evaluation of condition fixed) into compiler*.h, even if we change the
name of the macro.  The alternatives are to a.) further spitting out the
pieces of it into separate little macros (like
__compiletime_error_fallback), which I'm not fond of or b.) allow bug.h
to hold details about compiler functionality, which doesn't seem right
at all.  Let me play with this some and see what I can figure out.

>
>> I guess I'll fix it up (and address the emails on the other patches)
>> and do a v5 then for the whole set? (is that the right way to resubmit
>> with these corrections?)
> Well, you could wait a couple of days first to gather feedback from
> other people and then resend. This way you give chance to people to take
> a look without them seeing too many versions of the patchset and getting
> confused.
>
> What I always do is send out the patchset, collect and discuss changes,
> add in the required changes and test it while the discussions go on.
> After they settle down (and they do in a couple of days, in most cases)
> I then send out the newly tested version out.
>
> That whole exercise takes more or less a week if you're doing other
> stuff in between :)

Ahh, helpful guidelines, thanks so much! :)

Re: [PATCH v4 6/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Daniel Santos]

On 10/31/2012 06:06 AM, Borislav Petkov wrote:
>> Realistically, a single macro could be defined in compiler*.h that
>> encapsulates the entirety of this mechanism and only exposes a "black
>> box" macro, that will simply expand to something that breaks the build
>> in the most appropriate fashion based upon the version of gcc.  In
>> essence, the new BUILD_BUG_ON_MSG macro attempts to fill that roll.
>
> Yes.

OK, so I have two solutions, one I like and one that I don't.  Both of
these solutions will use the __compiletime_error_fallback macro, but
cleaned up slightly and it will only be used from within compiler.h (so
it becomes a private macro).

#ifndef __compiletime_error
# define __compiletime_error(message)
# define __compiletime_error_fallback(condition) \
        do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
#else
# define __compiletime_error_fallback(condition) do { } while (0)
#endif

And now let me present the solution that I do not like.

// compiler.h (after the above snippet)

#define __compiletime_error_invoke(condition, func)             \
        do {                                                    \
                bool __cond = !!(condition);                    \
                if (__cond)                                     \
                        func();                                 \
                __compiletime_error_fallback(__cond);           \
        } while (0)
#endif


// bug.h
...
#define __BUILD_BUG_INTERNAL(condition, msg, line)              \
        do {                                                    \
                extern void __build_bug_on_failed_ ## line(void)\
                                __compiletime_error(msg);       \
                __compiletime_error_invoke(condition,           \
                                __build_bug_on_failed_ ## line) \
        } while (0)

#define _BUILD_BUG_INTERNAL(condition, msg, line) \
        __BUILD_BUG_INTERNAL(condition, msg, line)

Rather than using __compiletime_error_fallback externally anywhere, we
just use it in another macro in compiler.h. Then, this
__compiletime_error_invoke macro is actually called to invoke the
error.  This problem is that this is highly disjointed; we end up with
large parts of the implementation in both compiler.h and in bug.h.
(also, I think we would need another macro to expand the concatenation
of __build_bug_on_failed_ ## line, I didn't test the above).

If we are going to move this level of detail out of bug.h, I think we
should move *all* of it.

// compiler.h
...

#define __compiletime_assert(condition, msg, __func)                    \
        do {                                                            \
                bool __cond = !!(condition);                            \
                extern void __func(void) __compiletime_error(msg);      \
                if (__cond)                                             \
                        __func();                                       \
                __compiletime_error_fallback(__cond);                   \
        } while (0)

#define _compiletime_assert(condition, msg, __func) \
        __compiletime_assert(condition, msg, __func)

/**
 * compiletime_assert - some documentation...
 */
#define compiletime_assert(condition, msg) \
        __compiletime_assert(condition, msg, __compiletime_assert_ ##
__LINE__)


// bug.h -- remove *BUILD_BUG_INTERNAL macros entirely and just chance this:

#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(cond, msg)

To me, this is much cleaner. It will give all compile-time assertions
the same base function name, but this shouldn't be much of a problem
since the new error attribute will spit out a nice detailed error
message at the point the error occurs and few people (if any?) should be
having to track this down from the link-time error. Even if you are
having to track it down just from a link-time error, it will tell you
the object file that the function was called from and the line number is
embedded in the function name, so it wouldn't be too hard. For example,
it's possible that the link-time error may be the only thing that breaks
on Intel or some other compilers (clang?). Having the full
implementation in compiler*.h allows for easier tweaking to suit various
compilers as well. (I may need to load up intel's latest compiler and
see how it is there).

Anyway, please let me know if you like it.

Daniel

[PATCH v5 0/9] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

 include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
 include/linux/compiler-gcc.h  |    3 ++
 include/linux/compiler-gcc3.h |    8 +++---
 include/linux/compiler-gcc4.h |   28 ++++++++++++------------
 include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
 5 files changed, 76 insertions(+), 42 deletions(-)

Changes in v5:
o Move BUILD_BUG* guts to a new compiletime_assert() macro in compiler.h.
o Fix a double-evaluation problem.
o Fix another bad macro definition when __CHECKER__ defined.

Changes in v4:
o Squash a minor commit (per Borislav Petkov)
o Change some comment text (per Borislav Petkov)
o Add some acks

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets and is based off of linux-next.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve
the manageability of of compiler features at various versions (when they
are broken, etc.), add some needed features to bug.h and clean that up as
well.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701).
o Reorder all features based upon the version introduced (readability).
o Change all version checks to use GCC_VERSION.
o Remove redundant __linktime_error macro.
o Introduce compiletime_assert() macro.

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Remove duplicate error messages in some cases.
o Fix double-evaluation problem in BUILD_BUG_ON.
o Fix bad macro definitions when using __CHECKER__.
o Introduce BUILD_BUG_ON_MSG and clean up the implementations of the
  BUILD_BUG* macros.

[PATCH v5 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 412bc6c..8914293 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH v5 2/9] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH v5 3/9] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8914293..9755029 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH v5 4/9] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..298a916 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 9755029..7f143ac 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b121554..cbf6d9d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -299,9 +299,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v5 5/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, both BUILD_BUG_ON_NOT_POWER_OF_2 and BUILD_BUG_ON was
evaluating to nothing in this case, and we want (0) since this is a
function-like macro that will be followed by a semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 298a916..1b2465d 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -12,10 +12,10 @@ enum bug_trap_type {
 struct pt_regs;
 
 #ifdef __CHECKER__
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.3.4

[PATCH v5 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[danielfsantos]

When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
the condition will be evaulated twice, possibily with side-effects.
This patch eliminates that error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 1b2465d..ccd44ce 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -58,8 +58,9 @@ struct pt_regs;
 extern int __build_bug_on_failed;
 #define BUILD_BUG_ON(condition)					\
 	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+		bool __cond = !!(condition);			\
+		((void)sizeof(char[1 - 2*!!(__cond)]));		\
+		if (__cond) __build_bug_on_failed = 1;		\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v5 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Also, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |   32 +++++++++++++++++++-------------
 1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index ccd44ce..dd4f506 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -42,25 +43,30 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
- * The implementation uses gcc's reluctance to create a negative array, but
- * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		bool __cond = !!(condition);			\
-		((void)sizeof(char[1 - 2*!!(__cond)]));		\
-		if (__cond) __build_bug_on_failed = 1;		\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		bool __cond = !!(condition);				\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		if (__cond)						\
+			__build_bug_on_failed();			\
+		((void)sizeof(char[1 - 2*!!(__cond)]));			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v5 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used.  The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized.  However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    2 +-
 include/linux/compiler.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index dd4f506..125e744 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -66,7 +66,7 @@ struct pt_regs;
 			__compiletime_error("BUILD_BUG_ON failed");	\
 		if (__cond)						\
 			__build_bug_on_failed();			\
-		((void)sizeof(char[1 - 2*!!(__cond)]));			\
+		__compiletime_error_fallback(__cond);			\
 	} while(0)
 #endif
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cbf6d9d..8e5b9d5 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -298,7 +298,12 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition) \
+	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+#else
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v5 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[danielfsantos]

Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following the tradition of
the POSIX assert macro, compiletime_assert creates a build-time error
when the supplied condition is *false*.

Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistient with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.

Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |   28 +++++++++++++---------------
 include/linux/compiler.h |   24 ++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 125e744..31a1310 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,6 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -39,6 +40,15 @@ struct pt_regs;
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
 /**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+
+/**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
  *
@@ -59,15 +69,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		bool __cond = !!(condition);				\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		if (__cond)						\
-			__build_bug_on_failed();			\
-		__compiletime_error_fallback(__cond);			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -77,12 +80,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 8e5b9d5..57878f3 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -304,6 +304,30 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 # define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 
+#define __compiletime_assert(condition, msg, __func)			\
+	do {								\
+		bool __cond = !(condition);				\
+		extern void __func(void) __compiletime_error(msg);	\
+		if (__cond)						\
+			__func();					\
+		__compiletime_error_fallback(__cond);			\
+	} while (0)
+
+#define _compiletime_assert(condition, msg, __func) \
+	__compiletime_assert(condition, msg, __func)
+
+/**
+ * compiletime_assert - break build and emit msg if condition is false
+ * @condition: a compile-time constant condition to check
+ * @msg:       a message to emit if condition is false
+ *
+ * In tradition of POSIX assert, this macro will break the build if the
+ * supplied condition is *false*, emitting the supplied error message if the
+ * compiler has support to do so.
+ */
+#define compiletime_assert(condition, msg) \
+	_compiletime_assert(condition, msg, __compiletime_assert_ ## __LINE__)
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

Re: [PATCH v5 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

Borislav,

Please note that this patch has changed slightly since you Acked it.  I
have moved the location of the negative-size array code to the end of
the macro.  I don't think this really matters honestly, but I figured
this was the best place to put that change.

Daniel

On 11/13/2012 04:13 PM, danielfsantos@att.net wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will.  This patch modifies
> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> function attribute so that you don't have to build the entire kernel to
> discover that you have a problem, and then enjoy trying to track it down
> from a link-time error.
>
> Also, we are only including asm/bug.h and then expecting that
> linux/compiler.h will eventually be included to define __linktime_error
> (used in BUILD_BUG_ON). This patch includes it directly for clarity and
> to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
> changed or not including linux/compiler.h for some reason.
>
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> Acked-by: Borislav Petkov <bp@alien8.de>
> ---
>  include/linux/bug.h |   32 +++++++++++++++++++-------------
>  1 files changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index ccd44ce..dd4f506 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -2,6 +2,7 @@
>  #define _LINUX_BUG_H
>  
>  #include <asm/bug.h>
> +#include <linux/compiler.h>
>  
>  enum bug_trap_type {
>  	BUG_TRAP_TYPE_NONE = 0,
> @@ -42,25 +43,30 @@ struct pt_regs;
>   * @condition: the condition which the compiler should know is false.
>   *
>   * If you have some code which relies on certain constants being equal, or
> - * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> + * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>   * detect if someone changes it.
>   *
> - * The implementation uses gcc's reluctance to create a negative array, but
> - * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
> - * to inline functions).  So as a fallback we use the optimizer; if it can't
> - * prove the condition is false, it will cause a link error on the undefined
> - * "__build_bug_on_failed".  This error message can be harder to track down
> - * though, hence the two different methods.
> + * The implementation uses gcc's reluctance to create a negative array, but gcc
> + * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
> + * inline functions).  Luckily, in 4.3 they added the "error" function
> + * attribute just for this type of case.  Thus, we use a negative sized array
> + * (should always create an error on gcc versions older than 4.4) and then call
> + * an undefined function with the error attribute (should always create an
> + * error on gcc 4.3 and later).  If for some reason, neither creates a
> + * compile-time error, we'll still have a link-time error, which is harder to
> + * track down.
>   */
>  #ifndef __OPTIMIZE__
>  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>  #else
> -extern int __build_bug_on_failed;
> -#define BUILD_BUG_ON(condition)					\
> -	do {							\
> -		bool __cond = !!(condition);			\
> -		((void)sizeof(char[1 - 2*!!(__cond)]));		\
> -		if (__cond) __build_bug_on_failed = 1;		\
> +#define BUILD_BUG_ON(condition)						\
> +	do {								\
> +		bool __cond = !!(condition);				\
> +		extern void __build_bug_on_failed(void)			\
> +			__compiletime_error("BUILD_BUG_ON failed");	\
> +		if (__cond)						\
> +			__build_bug_on_failed();			\
> +		((void)sizeof(char[1 - 2*!!(__cond)]));			\
>  	} while(0)
>  #endif
>  

Re: [PATCH v5 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[Borislav Petkov]

On Tue, Nov 13, 2012 at 04:24:15PM -0600, Daniel Santos wrote:
> Borislav,
> 
> Please note that this patch has changed slightly since you Acked it.  I
> have moved the location of the negative-size array code to the end of
> the macro.  I don't think this really matters honestly, but I figured
> this was the best place to put that change.

Yes, that's fine.

Thanks.

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[Borislav Petkov]

On Tue, Nov 13, 2012 at 04:13:38PM -0600, danielfsantos@att.net wrote:
> When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
> the condition will be evaulated twice, possibily with side-effects.
> This patch eliminates that error.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 1b2465d..ccd44ce 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -58,8 +58,9 @@ struct pt_regs;
>  extern int __build_bug_on_failed;
>  #define BUILD_BUG_ON(condition)					\
>  	do {							\
> -		((void)sizeof(char[1 - 2*!!(condition)]));	\
> -		if (condition) __build_bug_on_failed = 1;	\
> +		bool __cond = !!(condition);			\
> +		((void)sizeof(char[1 - 2*!!(__cond)]));		\

No need for the !!(__cond) here because you've done it in the line
above. IOW,

	bool __cond = !!(condition);
	((void)sizeof(char[1 - 2 * __cond]));

which is even a bit more readable, as a matter of fact.

> +		if (__cond) __build_bug_on_failed = 1;		\
>  	} while(0)
>  #endif

Thanks.

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 5/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[Borislav Petkov]

On Tue, Nov 13, 2012 at 04:13:37PM -0600, danielfsantos@att.net wrote:
> When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
> However, both BUILD_BUG_ON_NOT_POWER_OF_2 and BUILD_BUG_ON was
> evaluating to nothing in this case, and we want (0) since this is a
> function-like macro that will be followed by a semicolon.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Borislav Petkov]

On Tue, Nov 13, 2012 at 04:13:40PM -0600, danielfsantos@att.net wrote:
> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
> creating compile-time errors required a little trickery.
> BUILD_BUG{,_ON} uses this attribute when available to generate
> compile-time errors, but also uses the negative-sized array trick for
> older compilers, resulting in two error messages in some cases.  The
> reason it's "some" cases is that as of gcc 4.4, the negative-sized array
> will not create an error in some situations, like inline functions.
> 
> This patch replaces the negative-sized array code with the new
> __compiletime_error_fallback() macro which expands to the same thing
> unless the the error attribute is available, in which case it expands to
> do{}while(0), resulting in exactly one compile-time error on all
> versions of gcc.
> 
> Note that we are not changing the negative-sized array code for the
> unoptimized version of BUILD_BUG_ON, since it has the potential to catch
> problems that would be disabled in later versions of gcc were
> __compiletime_error_fallback used.  The reason is that that an
> unoptimized build can't always remove calls to an error-attributed
> function call (like we are using) that should effectively become dead
> code if it were optimized.  However, using a negative-sized array with a
> similar value will not result in an false-positive (error). The only
> caveat being that it will also fail to catch valid conditions, which we
> should be expecting in an unoptimized build anyway.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
> ---
>  include/linux/bug.h      |    2 +-
>  include/linux/compiler.h |    5 +++++
>  2 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index dd4f506..125e744 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -66,7 +66,7 @@ struct pt_regs;
>  			__compiletime_error("BUILD_BUG_ON failed");	\
>  		if (__cond)						\
>  			__build_bug_on_failed();			\
> -		((void)sizeof(char[1 - 2*!!(__cond)]));			\
> +		__compiletime_error_fallback(__cond);			\

We're passing an already evaluated __cond here which gets doubly-negated
again in __compiletime_error_fallback. If __compiletime_error_fallback
is going to be called only from BUILD_BUG_ON, then its definition should
be:

	do { ((void)sizeof(char[1 - 2 * (condition)])); } while (0)

i.e., without the !!.


>  	} while(0)
>  #endif
>  
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index cbf6d9d..8e5b9d5 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -298,7 +298,12 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>  #endif
>  #ifndef __compiletime_error
>  # define __compiletime_error(message)
> +# define __compiletime_error_fallback(condition) \
> +	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
> +#else
> +# define __compiletime_error_fallback(condition) do { } while (0)
>  #endif
> +
>  /*
>   * Prevent the compiler from merging or refetching accesses.  The compiler
>   * is also forbidden from reordering successive instances of ACCESS_ONCE(),
> -- 
> 1.7.3.4

Thanks.

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[Borislav Petkov]

On Tue, Nov 13, 2012 at 04:13:41PM -0600, danielfsantos@att.net wrote:
> Introduce compiletime_assert to compiler.h, which moves the details of
> how to break a build and emit an error message for a specific compiler
> to the headers where these details should be. Following the tradition of
> the POSIX assert macro, compiletime_assert creates a build-time error
> when the supplied condition is *false*.
> 
> Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
> compiletime_assert, inverting the logic, so that it fails when the
> condition is *true*, consistient with the language "build bug on." This
> macro allows you to specify the error message you want emitted when the
> supplied condition is true.
> 
> Finally, we remove all other code from bug.h that mucks with these
> details (BUILD_BUG & BUILD_BUG_ON), and have them all call
> BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but also
> prevents the possibility of code being changed for one macro and not for
> the other (which was previously the case for BUILD_BUG and
> BUILD_BUG_ON).
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Looks nice and clean.

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[Daniel Santos]

On 11/15/2012 09:07 AM, Borislav Petkov wrote:
> On Tue, Nov 13, 2012 at 04:13:38PM -0600, danielfsantos@att.net wrote:
>> When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
>> the condition will be evaulated twice, possibily with side-effects.
>> This patch eliminates that error.
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>> ---
>>  include/linux/bug.h |    5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>> index 1b2465d..ccd44ce 100644
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -58,8 +58,9 @@ struct pt_regs;
>>  extern int __build_bug_on_failed;
>>  #define BUILD_BUG_ON(condition)					\
>>  	do {							\
>> -		((void)sizeof(char[1 - 2*!!(condition)]));	\
>> -		if (condition) __build_bug_on_failed = 1;	\
>> +		bool __cond = !!(condition);			\
>> +		((void)sizeof(char[1 - 2*!!(__cond)]));		\
> No need for the !!(__cond) here because you've done it in the line
> above. IOW,
>
> 	bool __cond = !!(condition);
> 	((void)sizeof(char[1 - 2 * __cond]));
>
> which is even a bit more readable, as a matter of fact.
Ah yes. I did notice that at one point, but I think it slipped my mind. 
Also, the kernel has introduced me to the usage of the !! construct, of
which I'm well versed in its affects in various situations and how gcc's
optimizer ends up treating its usage, so probably another reason I
didn't change it immediately. But it's basically shorthand for the
expression (condition ? 1 : 0), correct? Or are there other details in
the C standard that makes it different in some cases?

Thanks,
Daniel

Re: [PATCH v5 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Daniel Santos]

On 11/15/2012 09:08 AM, Borislav Petkov wrote:
> On Tue, Nov 13, 2012 at 04:13:40PM -0600, danielfsantos@att.net wrote:
>> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
>> creating compile-time errors required a little trickery.
>> BUILD_BUG{,_ON} uses this attribute when available to generate
>> compile-time errors, but also uses the negative-sized array trick for
>> older compilers, resulting in two error messages in some cases.  The
>> reason it's "some" cases is that as of gcc 4.4, the negative-sized array
>> will not create an error in some situations, like inline functions.
>>
>> This patch replaces the negative-sized array code with the new
>> __compiletime_error_fallback() macro which expands to the same thing
>> unless the the error attribute is available, in which case it expands to
>> do{}while(0), resulting in exactly one compile-time error on all
>> versions of gcc.
>>
>> Note that we are not changing the negative-sized array code for the
>> unoptimized version of BUILD_BUG_ON, since it has the potential to catch
>> problems that would be disabled in later versions of gcc were
>> __compiletime_error_fallback used.  The reason is that that an
>> unoptimized build can't always remove calls to an error-attributed
>> function call (like we are using) that should effectively become dead
>> code if it were optimized.  However, using a negative-sized array with a
>> similar value will not result in an false-positive (error). The only
>> caveat being that it will also fail to catch valid conditions, which we
>> should be expecting in an unoptimized build anyway.
>>
>> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
>> ---
>>  include/linux/bug.h      |    2 +-
>>  include/linux/compiler.h |    5 +++++
>>  2 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>> index dd4f506..125e744 100644
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -66,7 +66,7 @@ struct pt_regs;
>>  			__compiletime_error("BUILD_BUG_ON failed");	\
>>  		if (__cond)						\
>>  			__build_bug_on_failed();			\
>> -		((void)sizeof(char[1 - 2*!!(__cond)]));			\
>> +		__compiletime_error_fallback(__cond);			\
> We're passing an already evaluated __cond here which gets doubly-negated
> again in __compiletime_error_fallback. If __compiletime_error_fallback
> is going to be called only from BUILD_BUG_ON, then its definition should
> be:
>
> 	do { ((void)sizeof(char[1 - 2 * (condition)])); } while (0)
>
> i.e., without the !!.
Yeah, I agree. Also, with the complexity, I think a few more comments
can be helpful in compiler.h to clarify what these macros are for more
specifically.

On another note, I have a "part two" set of patches for bug.h &
compiler*.h that does some other stuff (more cleanup & restructuring)
and this is making me think about that more.  My thought about
__compiletime_error_fallback is that it should be called only from
within compiler.h (as in the following patch) and basically just be a
private macro.  However, we still use the use the negative sized array
trick for the unoptimized version of BUILD_BUG_ON (which may have
limited meaning), and we also use a negative bit specifier on a bitfield
in BUILD_BUG_ON_ZERO and BUILD_BUG_ON_NULL (which I treat some in my
other patches as well).  But my thought is that it may be helpful to
encapsulate these tricks into (public) macros in compiler*.h, such as
"compiletime_assert_negarray" and "compiletime_assert_negbitfiled" and
then have __compiletime_error_fallback expand to
compiletime_assert_negarray when it's needed and no-op when it's not.

This doesn't have to be decided now, but it's just a thought you gave me.

And in case you're wondering about the negative bit field,
BUILD_BUG_ON_{ZERO,NULL} can't call BUILD_BUG_ON in a complex expression
({ exp; exp; }) because it is evaluated outside of a function body and
gcc doesn't like that.  Thus, the following macro would, sadly, result
in errors:

#define BUILD_BUG_ON_ZERO(exp) ({BUILD_BUG_ON(exp); 0;})

However, it would not be an error to call an __alwaysinline function
that uses BUILD_BUG_ON, so I still have to explore that and make sure it
works in all scenarios (and compilers).

But back to *this* patch, I'll make that change now.

Thanks!
Daniel

Re: [PATCH v5 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[Daniel Santos]

On 11/13/2012 04:13 PM, danielfsantos@att.net wrote:
> +#define __compiletime_assert(condition, msg, __func)			\
> +	do {								\
> +		bool __cond = !(condition);				\
> +		extern void __func(void) __compiletime_error(msg);	\
> +		if (__cond)						\
> +			__func();					\
> +		__compiletime_error_fallback(__cond);			\
> +	} while (0)
> +
> +#define _compiletime_assert(condition, msg, __func) \
> +	__compiletime_assert(condition, msg, __func)
> +
> +/**
> + * compiletime_assert - break build and emit msg if condition is false
> + * @condition: a compile-time constant condition to check
> + * @msg:       a message to emit if condition is false
> + *
> + * In tradition of POSIX assert, this macro will break the build if the
> + * supplied condition is *false*, emitting the supplied error message if the
> + * compiler has support to do so.
> + */
> +#define compiletime_assert(condition, msg) \
> +	_compiletime_assert(condition, msg, __compiletime_assert_ ## __LINE__)
> +

Whoops, this implementation pastes the tokens before allowing them to
expand, it should be something like this:

#define __compiletime_assert(condition, msg, __func) .... stuff
#define _compiletime_assert(condition, msg, prefix, suffix) \
        __compiletime_assert(condition, msg, prefix ## suffix)
#define compiletime_assert(condition, msg) \
        _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)

I'll fix that as well.

Daniel

Re: [PATCH v5 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[Borislav Petkov]

On Thu, Nov 15, 2012 at 01:11:15PM -0600, Daniel Santos wrote:
> Ah yes. I did notice that at one point, but I think it slipped
> my mind. Also, the kernel has introduced me to the usage of the
> !! construct, of which I'm well versed in its affects in various
> situations and how gcc's optimizer ends up treating its usage, so
> probably another reason I didn't change it immediately. But it's
> basically shorthand for the expression (condition ? 1 : 0), correct?

I don't think so: "!!" is simply a double negation which turns the
whatever wild construct you have into either 0 or 1, depending on what
it evaluates to.

But I don't know what the standard says so you'll have to check :-)

Thanks.

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Borislav Petkov]

On Thu, Nov 15, 2012 at 01:44:45PM -0600, Daniel Santos wrote:
> Yeah, I agree. Also, with the complexity, I think a few more comments
> can be helpful in compiler.h to clarify what these macros are for more
> specifically.

>From what I've read so far the comments are fine but if you want to be
more descriptive then sure, by all means. Just don't let them grow out
of proportion - keep them simple and succinct.

> On another note, I have a "part two" set of patches for bug.h &
> compiler*.h that does some other stuff (more cleanup & restructuring)
> and this is making me think about that more.  My thought about
> __compiletime_error_fallback is that it should be called only from
> within compiler.h (as in the following patch) and basically just be a
> private macro.  However, we still use the use the negative sized array
> trick for the unoptimized version of BUILD_BUG_ON (which may have
> limited meaning), and we also use a negative bit specifier on a bitfield
> in BUILD_BUG_ON_ZERO and BUILD_BUG_ON_NULL (which I treat some in my
> other patches as well).  But my thought is that it may be helpful to
> encapsulate these tricks into (public) macros in compiler*.h, such as
> "compiletime_assert_negarray" and "compiletime_assert_negbitfiled" and
> then have __compiletime_error_fallback expand to
> compiletime_assert_negarray when it's needed and no-op when it's not.
> 
> This doesn't have to be decided now, but it's just a thought you gave me.

I dunno. I'm thinking that maybe making them more unreadable for no
apparent reason might be simply too much. They're fine the way they are
now, if you ask me.

> And in case you're wondering about the negative bit field,
> BUILD_BUG_ON_{ZERO,NULL} can't call BUILD_BUG_ON in a complex expression
> ({ exp; exp; }) because it is evaluated outside of a function body and
> gcc doesn't like that.  Thus, the following macro would, sadly, result
> in errors:
> 
> #define BUILD_BUG_ON_ZERO(exp) ({BUILD_BUG_ON(exp); 0;})
> 
> However, it would not be an error to call an __alwaysinline function
> that uses BUILD_BUG_ON, so I still have to explore that and make sure it
> works in all scenarios (and compilers).

Ok, I see your point. Think of it this way: if unifying those macros can
only happen at the expense of readability or performance then maybe it
is not worth the trouble. If, OTOH, you can think of something slick and
pretty, then go ahead :).

HTH.

-- 
Regards/Gruss,
Boris.

Re: [PATCH v5 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[Daniel Santos]

On 11/17/2012 08:38 AM, Borislav Petkov wrote:
> On Thu, Nov 15, 2012 at 01:11:15PM -0600, Daniel Santos wrote:
>> Ah yes. I did notice that at one point, but I think it slipped
>> my mind. Also, the kernel has introduced me to the usage of the
>> !! construct, of which I'm well versed in its affects in various
>> situations and how gcc's optimizer ends up treating its usage, so
>> probably another reason I didn't change it immediately. But it's
>> basically shorthand for the expression (condition ? 1 : 0), correct?

Oh, this is embarrassing, The sentence above should have read:

... the kernel has introduced me to the usage of the !! construct, of which I'm *not* well versed in ...

hah! oh well


> I don't think so: "!!" is simply a double negation which turns the
> whatever wild construct you have into either 0 or 1, depending on what
> it evaluates to.
>
> But I don't know what the standard says so you'll have to check :-)

Here we go, from section §6.5.3.3:

The result of the logical negation operator ! is 0 if the value of its
operand compares unequal to 0, 1 if the value of its operand compares
equal to 0. The result has type int. The expression !E is equivalent to
(0==E).

I simply wasn't aware that it promised a "true" value to be one
exactly.  Hurray for expanding horizons! :)

Daniel

[PATCH v6 0/9] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

 include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
 include/linux/compiler-gcc.h  |    3 ++
 include/linux/compiler-gcc3.h |    8 +++---
 include/linux/compiler-gcc4.h |   28 ++++++++++++------------
 include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
 5 files changed, 76 insertions(+), 42 deletions(-)

Changes in v6:
o Remove extraneous double negation
o Fixed faulty macro expansion in last patch

Changes in v5:
o Move BUILD_BUG* guts to a new compiletime_assert() macro in compiler.h.
o Fix a double-evaluation problem.
o Fix another bad macro definition when __CHECKER__ defined.

Changes in v4:
o Squash a minor commit (per Borislav Petkov)
o Change some comment text (per Borislav Petkov)
o Add some acks

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets and is based off of linux-next.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve
the manageability of of compiler features at various versions (when they
are broken, etc.), add some needed features to bug.h and clean that up as
well.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701).
o Reorder all features based upon the version introduced (readability).
o Change all version checks to use GCC_VERSION.
o Remove redundant __linktime_error macro.
o Introduce compiletime_assert() macro.

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Remove duplicate error messages in some cases.
o Fix double-evaluation problem in BUILD_BUG_ON.
o Fix bad macro definitions when using __CHECKER__.
o Introduce BUILD_BUG_ON_MSG and clean up the implementations of the
  BUILD_BUG* macros.

[PATCH v6 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 412bc6c..8914293 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -31,6 +35,12 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -46,8 +56,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -56,10 +65,3 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
-- 
1.7.3.4

[PATCH v6 2/9] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.3.4

[PATCH v6 3/9] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8914293..9755029 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.3.4

[PATCH v6 4/9] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..298a916 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 9755029..7f143ac 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #ifndef __CHECKER__
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b121554..cbf6d9d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -299,9 +299,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v6 5/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, both BUILD_BUG_ON_NOT_POWER_OF_2 and BUILD_BUG_ON was
evaluating to nothing in this case, and we want (0) since this is a
function-like macro that will be followed by a semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 298a916..1b2465d 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -12,10 +12,10 @@ enum bug_trap_type {
 struct pt_regs;
 
 #ifdef __CHECKER__
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.3.4

[PATCH v6 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[danielfsantos]

When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
the condition will be evaulated twice, possibily with side-effects.
This patch eliminates that error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 1b2465d..98bdbb3d 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -58,8 +58,9 @@ struct pt_regs;
 extern int __build_bug_on_failed;
 #define BUILD_BUG_ON(condition)					\
 	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+		bool __cond = !!(condition);			\
+		((void)sizeof(char[1 - 2 * __cond]));		\
+		if (__cond) __build_bug_on_failed = 1;		\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v6 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Also, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |   32 +++++++++++++++++++-------------
 1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 98bdbb3d..eb6d715 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -42,25 +43,30 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
- * The implementation uses gcc's reluctance to create a negative array, but
- * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		bool __cond = !!(condition);			\
-		((void)sizeof(char[1 - 2 * __cond]));		\
-		if (__cond) __build_bug_on_failed = 1;		\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		bool __cond = !!(condition);				\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		if (__cond)						\
+			__build_bug_on_failed();			\
+		((void)sizeof(char[1 - 2 * __cond]));			\
 	} while(0)
 #endif
 
-- 
1.7.3.4

[PATCH v6 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used.  The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized.  However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    2 +-
 include/linux/compiler.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index eb6d715..125e744 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -66,7 +66,7 @@ struct pt_regs;
 			__compiletime_error("BUILD_BUG_ON failed");	\
 		if (__cond)						\
 			__build_bug_on_failed();			\
-		((void)sizeof(char[1 - 2 * __cond]));			\
+		__compiletime_error_fallback(__cond);			\
 	} while(0)
 #endif
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cbf6d9d..8e5b9d5 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -298,7 +298,12 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition) \
+	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+#else
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

[PATCH v6 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[danielfsantos]

Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the tradition
of the POSIX assert macro, compiletime_assert creates a build-time error
when the supplied condition is *false*.

Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.

Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |   28 +++++++++++++---------------
 include/linux/compiler.h |   26 +++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 125e744..31a1310 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -16,6 +16,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -39,6 +40,15 @@ struct pt_regs;
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
 /**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+
+/**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
  *
@@ -59,15 +69,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		bool __cond = !!(condition);				\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		if (__cond)						\
-			__build_bug_on_failed();			\
-		__compiletime_error_fallback(__cond);			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -77,12 +80,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 8e5b9d5..fcc3041 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -299,11 +299,35 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 # define __compiletime_error_fallback(condition) \
-	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+	do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
 #else
 # define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 
+#define __compiletime_assert(condition, msg, prefix, suffix)		\
+	do {								\
+		bool __cond = !(condition);				\
+		extern void prefix ## suffix(void) __compiletime_error(msg); \
+		if (__cond)						\
+			prefix ## suffix();				\
+		__compiletime_error_fallback(__cond);			\
+	} while (0)
+
+#define _compiletime_assert(condition, msg, prefix, suffix) \
+	__compiletime_assert(condition, msg, prefix, suffix)
+
+/**
+ * compiletime_assert - break build and emit msg if condition is false
+ * @condition: a compile-time constant condition to check
+ * @msg:       a message to emit if condition is false
+ *
+ * In tradition of POSIX assert, this macro will break the build if the
+ * supplied condition is *false*, emitting the supplied error message if the
+ * compiler has support to do so.
+ */
+#define compiletime_assert(condition, msg) \
+	_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.3.4

Re: [PATCH v6 0/9] Cleanup & new features for compiler*.h and bug.h

[Michel Lespinasse]

On Tue, Nov 20, 2012 at 12:42 PM,  <danielfsantos@att.net> wrote:
>
>  include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
>  include/linux/compiler-gcc.h  |    3 ++
>  include/linux/compiler-gcc3.h |    8 +++---
>  include/linux/compiler-gcc4.h |   28 ++++++++++++------------
>  include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
>  5 files changed, 76 insertions(+), 42 deletions(-)
>
> Changes in v6:
> o Remove extraneous double negation
> o Fixed faulty macro expansion in last patch

Acked-by: Michel Lespinasse <walken@google.com> on the entire v6 series.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [PATCH v6 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[Borislav Petkov]

On Tue, Nov 20, 2012 at 03:05:04PM -0600, danielfsantos@att.net wrote:
> When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
> the condition will be evaulated twice, possibily with side-effects.
> This patch eliminates that error.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
Boris.

Re: [PATCH v6 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[Borislav Petkov]

On Tue, Nov 20, 2012 at 03:05:06PM -0600, danielfsantos@att.net wrote:
> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
> creating compile-time errors required a little trickery.
> BUILD_BUG{,_ON} uses this attribute when available to generate
> compile-time errors, but also uses the negative-sized array trick for
> older compilers, resulting in two error messages in some cases.  The
> reason it's "some" cases is that as of gcc 4.4, the negative-sized array
> will not create an error in some situations, like inline functions.
> 
> This patch replaces the negative-sized array code with the new
> __compiletime_error_fallback() macro which expands to the same thing
> unless the the error attribute is available, in which case it expands to
> do{}while(0), resulting in exactly one compile-time error on all
> versions of gcc.
> 
> Note that we are not changing the negative-sized array code for the
> unoptimized version of BUILD_BUG_ON, since it has the potential to catch
> problems that would be disabled in later versions of gcc were
> __compiletime_error_fallback used.  The reason is that that an
> unoptimized build can't always remove calls to an error-attributed
> function call (like we are using) that should effectively become dead
> code if it were optimized.  However, using a negative-sized array with a
> similar value will not result in an false-positive (error). The only
> caveat being that it will also fail to catch valid conditions, which we
> should be expecting in an unoptimized build anyway.
> 
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

Acked-by: Borislav Petkov <bp@alien8.de>

-- 
Regards/Gruss,
Boris.

Re: [PATCH v6 0/9] Cleanup & new features for compiler*.h and bug.h

[Borislav Petkov]

On Tue, Nov 20, 2012 at 02:42:03PM -0600, danielfsantos@att.net wrote:
> 
>  include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
>  include/linux/compiler-gcc.h  |    3 ++
>  include/linux/compiler-gcc3.h |    8 +++---
>  include/linux/compiler-gcc4.h |   28 ++++++++++++------------
>  include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
>  5 files changed, 76 insertions(+), 42 deletions(-)

Ok,

this patchset is slowly but surely getting into a mergeable state and
could probably use wider testing in linux-next right about now.

Maybe akpm can pick it up into -mm so that it sees -next and then if all
is fine maybe find its way upstream in the next merge window, AFAICT.

Thanks.

-- 
Regards/Gruss,
Boris.

[PATCH v7 0/9] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

 include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
 include/linux/compiler-gcc.h  |    3 ++
 include/linux/compiler-gcc3.h |    8 +++---
 include/linux/compiler-gcc4.h |   36 +++++++++++++++---------------
 include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
 5 files changed, 80 insertions(+), 46 deletions(-)

This version just rebases against today's -next and with a slight modification
to CONFIG_ARCH_USE_BUILTIN_BSWAP code in in compiler-gcc4.h.

[PATCH v7 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc4.h |   26 ++++++++++++++------------
 1 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 662fd1b..78090c6 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -33,6 +37,12 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -48,8 +58,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -58,20 +67,13 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
 
 #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 40400
 #define __HAVE_BUILTIN_BSWAP32__
 #define __HAVE_BUILTIN_BSWAP64__
 #endif
-#if __GNUC_MINOR__ >= 8 || (defined(__powerpc__) && __GNUC_MINOR__ >= 6)
+#if GCC_VERSION >= 40800 || (defined(__powerpc__) && GCC_VERSION >= 40600)
 #define __HAVE_BUILTIN_BSWAP16__
 #endif
-#endif
+#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
-- 
1.7.8.6

[PATCH v7 2/9] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.8.6

[PATCH v7 3/9] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 78090c6..a9ffdfe 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -41,9 +41,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -58,9 +58,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
-- 
1.7.8.6

[PATCH v7 4/9] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index b1cf40d..2a11774 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -74,7 +74,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index a9ffdfe..68b162d 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
 #ifndef __CHECKER__
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index dd852b7..4c638be 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,9 +308,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6

[PATCH v7 5/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, both BUILD_BUG_ON_NOT_POWER_OF_2 and BUILD_BUG_ON was
evaluating to nothing in this case, and we want (0) since this is a
function-like macro that will be followed by a semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 2a11774..27d404f 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -12,11 +12,11 @@ enum bug_trap_type {
 struct pt_regs;
 
 #ifdef __CHECKER__
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
 #define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.8.6

[PATCH v7 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[danielfsantos]

When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
the condition will be evaulated twice, possibily with side-effects.
This patch eliminates that error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 27d404f..0d75762 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -59,8 +59,9 @@ struct pt_regs;
 extern int __build_bug_on_failed;
 #define BUILD_BUG_ON(condition)					\
 	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+		bool __cond = !!(condition);			\
+		((void)sizeof(char[1 - 2 * __cond]));		\
+		if (__cond) __build_bug_on_failed = 1;		\
 	} while(0)
 #endif
 
-- 
1.7.8.6

[PATCH v7 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Also, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |   32 +++++++++++++++++++-------------
 1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 0d75762..08d97e9 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -43,25 +44,30 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
- * The implementation uses gcc's reluctance to create a negative array, but
- * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		bool __cond = !!(condition);			\
-		((void)sizeof(char[1 - 2 * __cond]));		\
-		if (__cond) __build_bug_on_failed = 1;		\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		bool __cond = !!(condition);				\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		if (__cond)						\
+			__build_bug_on_failed();			\
+		((void)sizeof(char[1 - 2 * __cond]));			\
 	} while(0)
 #endif
 
-- 
1.7.8.6

[PATCH v7 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used.  The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized.  However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    2 +-
 include/linux/compiler.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 08d97e9..57c7688 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -67,7 +67,7 @@ struct pt_regs;
 			__compiletime_error("BUILD_BUG_ON failed");	\
 		if (__cond)						\
 			__build_bug_on_failed();			\
-		((void)sizeof(char[1 - 2 * __cond]));			\
+		__compiletime_error_fallback(__cond);			\
 	} while(0)
 #endif
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 4c638be..423bb6b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -307,7 +307,12 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition) \
+	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+#else
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6

[PATCH v7 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[danielfsantos]

Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the tradition
of the POSIX assert macro, compiletime_assert creates a build-time error
when the supplied condition is *false*.

Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.

Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |   28 +++++++++++++---------------
 include/linux/compiler.h |   26 +++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 57c7688..3c09a00 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -17,6 +17,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
 #define BUILD_BUG_ON_INVALID(e) (0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -40,6 +41,15 @@ struct pt_regs;
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
 /**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+
+/**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
  *
@@ -60,15 +70,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		bool __cond = !!(condition);				\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		if (__cond)						\
-			__build_bug_on_failed();			\
-		__compiletime_error_fallback(__cond);			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -78,12 +81,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 423bb6b..10b8f23 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,11 +308,35 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 # define __compiletime_error_fallback(condition) \
-	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+	do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
 #else
 # define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 
+#define __compiletime_assert(condition, msg, prefix, suffix)		\
+	do {								\
+		bool __cond = !(condition);				\
+		extern void prefix ## suffix(void) __compiletime_error(msg); \
+		if (__cond)						\
+			prefix ## suffix();				\
+		__compiletime_error_fallback(__cond);			\
+	} while (0)
+
+#define _compiletime_assert(condition, msg, prefix, suffix) \
+	__compiletime_assert(condition, msg, prefix, suffix)
+
+/**
+ * compiletime_assert - break build and emit msg if condition is false
+ * @condition: a compile-time constant condition to check
+ * @msg:       a message to emit if condition is false
+ *
+ * In tradition of POSIX assert, this macro will break the build if the
+ * supplied condition is *false*, emitting the supplied error message if the
+ * compiler has support to do so.
+ */
+#define compiletime_assert(condition, msg) \
+	_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6

Re: [PATCH v7 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[Daniel Santos]

On 01/01/2013 03:09 PM, danielfsantos@att.net wrote:

>   #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
> -#if __GNUC_MINOR__>= 4
> +#if GCC_VERSION>= 40400
>   #define __HAVE_BUILTIN_BSWAP32__
>   #define __HAVE_BUILTIN_BSWAP64__
>   #endif
> -#if __GNUC_MINOR__>= 8 || (defined(__powerpc__)&&  __GNUC_MINOR__>= 6)
> +#if GCC_VERSION>= 40800 || (defined(__powerpc__)&&  GCC_VERSION>= 40600)
>   #define __HAVE_BUILTIN_BSWAP16__
>   #endif
> -#endif
> +#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
I'm terribly sorry, I appear to have broken bisectability here.

[PATCH v8 0/9] Cleanup & new features for compiler*.h and bug.h

[danielfsantos]

Well, it looks like my new version of git properly handles the
--in-reply-to switch now, so this patch set shouldn't be oddly threaded
like the last version.

 include/linux/bug.h           |   47 ++++++++++++++++++++++------------------
 include/linux/compiler-gcc.h  |    3 ++
 include/linux/compiler-gcc3.h |    8 +++---
 include/linux/compiler-gcc4.h |   36 +++++++++++++++---------------
 include/linux/compiler.h      |   32 +++++++++++++++++++++++++--
 5 files changed, 80 insertions(+), 46 deletions(-)

Changes in v8:
o Correct bisection issue

Changes in v7:
o Rebase onto next-20121224 & merge changes

Changes in v6:
o Remove extraneous double negation
o Fixed faulty macro expansion in last patch

Changes in v5:
o Move BUILD_BUG* guts to a new compiletime_assert() macro in compiler.h.
o Fix a double-evaluation problem.
o Fix another bad macro definition when __CHECKER__ defined.

Changes in v4:
o Squash a minor commit (per Borislav Petkov)
o Change some comment text (per Borislav Petkov)
o Add some acks

This patch set is a dependency of the generic red-black tree patch set, which
I have now split up into three smaller sets and is based off of linux-next.

The major aim of this patch set is to cleanup compiler-gcc*.h and improve
the manageability of of compiler features at various versions (when they
are broken, etc.), add some needed features to bug.h and clean that up as
well.

compiler-gcc*.h
o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701).
o Reorder all features based upon the version introduced (readability).
o Change all version checks to use GCC_VERSION.
o Remove redundant __linktime_error macro.
o Introduce compiletime_assert() macro.

bug.h
o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4
o Remove duplicate error messages in some cases.
o Fix double-evaluation problem in BUILD_BUG_ON.
o Fix bad macro definitions when using __CHECKER__.
o Introduce BUILD_BUG_ON_MSG and clean up the implementations of the
  BUILD_BUG* macros.

[PATCH v8 1/9] compiler-gcc4.h: Reorder macros based upon gcc ver

[danielfsantos]

This helps to keep the file from getting confusing, removes one
duplicate version check and should encourage future editors to put new
macros where they belong.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc4.h |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 662fd1b..c9785c2 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -13,6 +13,10 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
+#if __GNUC_MINOR__ > 0
+# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
+#endif
+
 #if __GNUC_MINOR__ >= 3
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
@@ -33,6 +37,12 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+#endif /* __GNUC_MINOR__ >= 3 */
+
 #if __GNUC_MINOR__ >= 5
 /*
  * Mark a position in code as unreachable.  This can be used to
@@ -48,8 +58,7 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif
-#endif
+#endif /* __GNUC_MINOR__ >= 5 */
 
 #if __GNUC_MINOR__ >= 6
 /*
@@ -58,13 +67,6 @@
 #define __visible __attribute__((externally_visible))
 #endif
 
-#if __GNUC_MINOR__ > 0
-#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#endif
-#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__)
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
-#endif
 
 #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
 #if __GNUC_MINOR__ >= 4
-- 
1.7.8.6

[PATCH v8 2/9] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[danielfsantos]

Throughout compiler*.h, many version checks are made.  These can be
simplified by using the macro that gcc's documentation recommends.
However, my primary reason for adding this is that I need bug-check
macros that are enabled at certain gcc versions and it's cleaner to use
this macro than the tradition method:

if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

If you add patch level, it gets this ugly:

if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
   __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

As opposed to:

if GCC_VERSION >= 40201

While having separate headers for gcc 3 & 4 eliminates some of this
verbosity, they can still be cleaned up by this.

See also:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: David Rientjes <rientjes@google.com>
---
 include/linux/compiler-gcc.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 6a6d7ae..24545cd 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -5,6 +5,9 @@
 /*
  * Common definitions for all gcc versions go here.
  */
+#define GCC_VERSION (__GNUC__ * 10000 \
+		   + __GNUC_MINOR__ * 100 \
+		   + __GNUC_PATCHLEVEL__)
 
 
 /* Optimization barrier */
-- 
1.7.8.6

[PATCH v8 3/9] compiler-gcc{3,4}.h: Use GCC_VERSION macro

[danielfsantos]

Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.)  This also makes it easy to
merge compiler-gcc{,3,4}.h should somebody want to.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/compiler-gcc3.h |    8 ++++----
 include/linux/compiler-gcc4.h |   20 ++++++++++----------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
 #error "Please don't include <linux/compiler-gcc3.h> directly, include <linux/compiler.h> instead."
 #endif
 
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
 # error Sorry, your compiler is too old - please upgrade it.
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
 # define __used			__attribute__((__used__))
 #else
 # define __used			__attribute__((__unused__))
 #endif
 
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
 #define __must_check		__attribute__((warn_unused_result))
 #endif
 
 #ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
 #   error "GCOV profiling support for gcc versions below 3.4 not included"
 # endif /* __GNUC_MINOR__ */
 #endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index c9785c2..a9ffdfe 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 &&  GCC_VERSION <= 40101
 #  error Your version of gcc miscompiles the __weak directive
 # endif
 #endif
@@ -13,11 +13,11 @@
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40100
 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
 #endif
 
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
 /* Mark functions as cold. gcc will assume any path leading to a call
    to them will be unlikely.  This means a lot of manual unlikely()s
    are unnecessary now for any paths leading to the usual suspects
@@ -41,9 +41,9 @@
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 #endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
 
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -58,9 +58,9 @@
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone	__attribute__((__noclone__))
 
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
 
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
 /*
  * Tell the optimizer that something else uses this function or variable.
  */
@@ -69,11 +69,11 @@
 
 
 #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 40400
 #define __HAVE_BUILTIN_BSWAP32__
 #define __HAVE_BUILTIN_BSWAP64__
 #endif
-#if __GNUC_MINOR__ >= 8 || (defined(__powerpc__) && __GNUC_MINOR__ >= 6)
+#if GCC_VERSION >= 40800 || (defined(__powerpc__) && GCC_VERSION >= 40600)
 #define __HAVE_BUILTIN_BSWAP16__
 #endif
-#endif
+#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
-- 
1.7.8.6

[PATCH v8 4/9] compiler{,-gcc4}.h, bug.h: Remove duplicate macros

[danielfsantos]

__linktime_error() does the same thing as __compiletime_error() and is
only used in bug.h.  Since the macro defines a function attribute that
will cause a failure at compile-time (not link-time), it makes more
sense to keep __compiletime_error(), which is also neatly mated with
__compiletime_warning().

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h           |    2 +-
 include/linux/compiler-gcc4.h |    2 --
 include/linux/compiler.h      |    3 ---
 3 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index b1cf40d..2a11774 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -74,7 +74,7 @@ extern int __build_bug_on_failed;
 #define BUILD_BUG()						\
 	do {							\
 		extern void __build_bug_failed(void)		\
-			__linktime_error("BUILD_BUG failed");	\
+			__compiletime_error("BUILD_BUG failed");\
 		__build_bug_failed();				\
 	} while (0)
 
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index a9ffdfe..68b162d 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -33,8 +33,6 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
-#define __linktime_error(message) __attribute__((__error__(message)))
-
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
 #ifndef __CHECKER__
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index dd852b7..4c638be 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,9 +308,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-#ifndef __linktime_error
-# define __linktime_error(message)
-#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6

[PATCH v8 5/9] bug.h: Fix BUILD_BUG_ON macro in __CHECKER__

[danielfsantos]

When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
However, both BUILD_BUG_ON_NOT_POWER_OF_2 and BUILD_BUG_ON was
evaluating to nothing in this case, and we want (0) since this is a
function-like macro that will be followed by a semicolon.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 2a11774..27d404f 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -12,11 +12,11 @@ enum bug_trap_type {
 struct pt_regs;
 
 #ifdef __CHECKER__
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
 #define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON(condition)
+#define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
-- 
1.7.8.6

[PATCH v8 6/9] bug.h: Prevent double evaulation of in BUILD_BUG_ON

[danielfsantos]

When calling BUILD_BUG_ON in an optimized build using gcc 4.3 and later,
the condition will be evaulated twice, possibily with side-effects.
This patch eliminates that error.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 27d404f..0d75762 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -59,8 +59,9 @@ struct pt_regs;
 extern int __build_bug_on_failed;
 #define BUILD_BUG_ON(condition)					\
 	do {							\
-		((void)sizeof(char[1 - 2*!!(condition)]));	\
-		if (condition) __build_bug_on_failed = 1;	\
+		bool __cond = !!(condition);			\
+		((void)sizeof(char[1 - 2 * __cond]));		\
+		if (__cond) __build_bug_on_failed = 1;		\
 	} while(0)
 #endif
 
-- 
1.7.8.6

[PATCH v8 7/9] bug.h: Make BUILD_BUG_ON generate compile-time error

[danielfsantos]

Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will.  This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.

Also, we are only including asm/bug.h and then expecting that
linux/compiler.h will eventually be included to define __linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in <arch>/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Acked-by: Borislav Petkov <bp@alien8.de>
---
 include/linux/bug.h |   32 +++++++++++++++++++-------------
 1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 0d75762..08d97e9 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
 #define _LINUX_BUG_H
 
 #include <asm/bug.h>
+#include <linux/compiler.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -43,25 +44,30 @@ struct pt_regs;
  * @condition: the condition which the compiler should know is false.
  *
  * If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
  * detect if someone changes it.
  *
- * The implementation uses gcc's reluctance to create a negative array, but
- * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions).  So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed".  This error message can be harder to track down
- * though, hence the two different methods.
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
  */
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)					\
-	do {							\
-		bool __cond = !!(condition);			\
-		((void)sizeof(char[1 - 2 * __cond]));		\
-		if (__cond) __build_bug_on_failed = 1;		\
+#define BUILD_BUG_ON(condition)						\
+	do {								\
+		bool __cond = !!(condition);				\
+		extern void __build_bug_on_failed(void)			\
+			__compiletime_error("BUILD_BUG_ON failed");	\
+		if (__cond)						\
+			__build_bug_on_failed();			\
+		((void)sizeof(char[1 - 2 * __cond]));			\
 	} while(0)
 #endif
 
-- 
1.7.8.6

[PATCH v8 8/9] compiler.h, bug.h: Prevent double error messages with BUILD_BUG{,_ON}

[danielfsantos]

Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases.  The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.

This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.

Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used.  The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized.  However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |    2 +-
 include/linux/compiler.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 08d97e9..57c7688 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -67,7 +67,7 @@ struct pt_regs;
 			__compiletime_error("BUILD_BUG_ON failed");	\
 		if (__cond)						\
 			__build_bug_on_failed();			\
-		((void)sizeof(char[1 - 2 * __cond]));			\
+		__compiletime_error_fallback(__cond);			\
 	} while(0)
 #endif
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 4c638be..423bb6b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -307,7 +307,12 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
+# define __compiletime_error_fallback(condition) \
+	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+#else
+# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6

[PATCH v8 9/9] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG

[danielfsantos]

Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the tradition
of the POSIX assert macro, compiletime_assert creates a build-time error
when the supplied condition is *false*.

Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.

Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG.  This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).

Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 include/linux/bug.h      |   28 +++++++++++++---------------
 include/linux/compiler.h |   26 +++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 57c7688..3c09a00 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -17,6 +17,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
 #define BUILD_BUG_ON_INVALID(e) (0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
 #else /* __CHECKER__ */
@@ -40,6 +41,15 @@ struct pt_regs;
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
 
 /**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ * 		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+
+/**
  * BUILD_BUG_ON - break compile if a condition is true.
  * @condition: the condition which the compiler should know is false.
  *
@@ -60,15 +70,8 @@ struct pt_regs;
 #ifndef __OPTIMIZE__
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
 #else
-#define BUILD_BUG_ON(condition)						\
-	do {								\
-		bool __cond = !!(condition);				\
-		extern void __build_bug_on_failed(void)			\
-			__compiletime_error("BUILD_BUG_ON failed");	\
-		if (__cond)						\
-			__build_bug_on_failed();			\
-		__compiletime_error_fallback(__cond);			\
-	} while(0)
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 #endif
 
 /**
@@ -78,12 +81,7 @@ struct pt_regs;
  * build time, you should use BUILD_BUG to detect if it is
  * unexpectedly used.
  */
-#define BUILD_BUG()						\
-	do {							\
-		extern void __build_bug_failed(void)		\
-			__compiletime_error("BUILD_BUG failed");\
-		__build_bug_failed();				\
-	} while (0)
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
 #endif	/* __CHECKER__ */
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 423bb6b..10b8f23 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,11 +308,35 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 # define __compiletime_error_fallback(condition) \
-	do { ((void)sizeof(char[1 - 2*!!(condition)])); } while (0)
+	do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
 #else
 # define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 
+#define __compiletime_assert(condition, msg, prefix, suffix)		\
+	do {								\
+		bool __cond = !(condition);				\
+		extern void prefix ## suffix(void) __compiletime_error(msg); \
+		if (__cond)						\
+			prefix ## suffix();				\
+		__compiletime_error_fallback(__cond);			\
+	} while (0)
+
+#define _compiletime_assert(condition, msg, prefix, suffix) \
+	__compiletime_assert(condition, msg, prefix, suffix)
+
+/**
+ * compiletime_assert - break build and emit msg if condition is false
+ * @condition: a compile-time constant condition to check
+ * @msg:       a message to emit if condition is false
+ *
+ * In tradition of POSIX assert, this macro will break the build if the
+ * supplied condition is *false*, emitting the supplied error message if the
+ * compiler has support to do so.
+ */
+#define compiletime_assert(condition, msg) \
+	_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
+
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
-- 
1.7.8.6