From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
Roland Dreier <rdreier@cisco•com>,
Andrew Morton <akpm@linux-foundation•org>
Subject: linux-next: manual merge of the rr tree with Linus' tree
Date: Mon, 18 Jan 2010 15:06:03 +1100 [thread overview]
Message-ID: <20100118150603.7bfde023.sfr@canb.auug.org.au> (raw)
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
include/linux/kernel.h between commit
cc8ef6eb21e964b1c5eb97b2d0e8ac9893e1bf86 ("kernel.h: add
BUILD_BUG_ON_NOT_POWER_OF_2()") from Linus' tree and commit
eb586ef779665b558aeafa9b948c0b005c5caadf
("misc:move-BUILD_BUG-et-al-inside-__KERNEL__") from the rr tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
diff --cc include/linux/kernel.h
index 328bca6,57ffaa0..0000000
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@@ -702,13 -702,59 +702,63 @@@ static inline void ftrace_dump(void) {
struct sysinfo;
extern int do_sysinfo(struct sysinfo *info);
- #endif /* __KERNEL__ */
+ /* Force a compilation error if condition is true, but also produce a
+ result (of value 0 and type size_t), so the expression can be used
+ e.g. in a structure initializer (or where-ever else comma expressions
+ aren't permitted). */
+ #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
+ #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+
+ /**
+ * BUILD_BUG_ON - break compile if a condition is true.
+ * @cond: 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
+ * 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.
+ */
+ #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; \
+ } while(0)
+ #endif
+
++/* Force a compilation error if a constant expression is not a power of 2 */
++#define BUILD_BUG_ON_NOT_POWER_OF_2(n) \
++ BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
++
+ /* Trap pasters of __FUNCTION__ at compile-time */
+ #define __FUNCTION__ (__func__)
+
+ /* This helps us to avoid #ifdef CONFIG_NUMA */
+ #ifdef CONFIG_NUMA
+ #define NUMA_BUILD 1
+ #else
+ #define NUMA_BUILD 0
+ #endif
+
+ /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */
+ #ifdef CONFIG_FTRACE_MCOUNT_RECORD
+ # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
+ #endif
+ #else /* __KERNEL__ */
#ifndef __EXPORTED_HEADERS__
- #ifndef __KERNEL__
#warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders
- #endif /* __KERNEL__ */
#endif /* __EXPORTED_HEADERS__ */
+ #endif /* !__KERNEL__ */
#define SI_LOAD_SHIFT 16
struct sysinfo {
next reply other threads:[~2010-01-18 4:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 4:06 Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-08-21 2:11 linux-next: manual merge of the rr tree with Linus' tree Stephen Rothwell
2012-05-23 2:15 Stephen Rothwell
2010-01-12 2:13 Stephen Rothwell
2009-12-17 2:07 Stephen Rothwell
2009-09-15 3:26 Stephen Rothwell
2009-08-24 3:07 Stephen Rothwell
2009-07-06 2:05 Stephen Rothwell
2009-06-29 3:43 Stephen Rothwell
2009-06-24 3:08 Stephen Rothwell
2009-06-12 3:54 Stephen Rothwell
2009-05-27 3:55 Stephen Rothwell
2009-04-16 2:19 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100118150603.7bfde023.sfr@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=akpm@linux-foundation$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=rdreier@cisco$(echo .)com \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox