Re: linux-next: tree build failure
On Tue, 2009-10-20 at 11:42 +1030, Rusty Russell wrote: > On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote: > > On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: > > > My perspective is that it just uncovered already existing brokenness. > > > > Sorry, I thought it was clear, but to be more explicit: I propose the > > following patch, which replaces the current BUILD_BUG_ON implementation > > with Rusty's version. > > OK, I switched my brain back on. Yeah, I agree: we may still want > BUILD_OR_RUNTIME_BUG_ON one day, but I like this. > > It's just missing the giant comment that it needs :) > > /** > * 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 is less neat, and can be harder to > * track down. > */ Do you want to put together a signed-off patch Rusty? It's your code, so I don't feel comfortable doing that. Once we have that, can we remove the mysterious MAYBE_BUILD_BUG_ON statements introduced in previous patches? (Does it BUG or doesn't it??) -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote: > On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: > > My perspective is that it just uncovered already existing brokenness. > > Sorry, I thought it was clear, but to be more explicit: I propose the > following patch, which replaces the current BUILD_BUG_ON implementation > with Rusty's version. OK, I switched my brain back on. Yeah, I agree: we may still want BUILD_OR_RUNTIME_BUG_ON one day, but I like this. It's just missing the giant comment that it needs :) /** * 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 is less neat, and can be harder to * track down. */ Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard 15.10.09 00:57 >>>
> >On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
> >> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
> >> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
> >>
> >> original: built but didn't work
> >> Jan's: doesn't build
> >> Rusty's: builds and works
> >>
> >> Where do you want to go from here?
> >
> >Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
> >build, and we still need to fix it.
>
> My perspective is that it just uncovered already existing brokenness. And
> honestly, I won't be able to get to look into this within the next days. (And
> btw., when I run into issues with other people's code changes, quite
> frequently I'm told to propose a patch, so I'm also having some
> philosophical problem understanding why I can't simply expect the same
> when people run into issues with changes I made, especially in cases like
> this where it wasn't me introducing the broken code.) So, if this can wait
> for a couple of days, I can try to find time to look into this. Otherwise, I'd
> rely on someone running into the actual issue to implement a solution.
Sorry, I thought it was clear, but to be more explicit: I propose the
following patch, which replaces the current BUILD_BUG_ON implementation
with Rusty's version.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -677,18 +677,19 @@ struct sysinfo {
char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
};
-/* Force a compilation error if condition is true */
-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
-
-/* Force a compilation error if condition is constant and true */
-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
-
-/* 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); }))
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+/* If it's a constant, catch it at compile time, otherwise at link time. */
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_ON(condition) \
+ do {
\
+ ((void)sizeof(char[1 - 2*!!(condition)]));
\
+ if (condition) __build_bug_on_failed = 1;
\
+ } while(0)
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+#endif
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
>>> Hollis Blanchard 15.10.09 00:57 >>> >On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote: >> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and >> also exposes the bug in kvmppc_account_exit_stat(). So to recap: >> >> original: built but didn't work >> Jan's: doesn't build >> Rusty's: builds and works >> >> Where do you want to go from here? > >Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the >build, and we still need to fix it. My perspective is that it just uncovered already existing brokenness. And honestly, I won't be able to get to look into this within the next days. (And btw., when I run into issues with other people's code changes, quite frequently I'm told to propose a patch, so I'm also having some philosophical problem understanding why I can't simply expect the same when people run into issues with changes I made, especially in cases like this where it wasn't me introducing the broken code.) So, if this can wait for a couple of days, I can try to find time to look into this. Otherwise, I'd rely on someone running into the actual issue to implement a solution. Jan -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote: > Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and > also exposes the bug in kvmppc_account_exit_stat(). So to recap: > > original: built but didn't work > Jan's: doesn't build > Rusty's: builds and works > > Where do you want to go from here? Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the build, and we still need to fix it. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2009-10-05 at 07:58 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard 02.10.09 17:48 >>>
> >On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
> >> The one Rusty suggested the other day may help here. I don't like it
> >> as a drop-in replacement for BUILD_BUG_ON() though (due to it
> >> deferring the error generated to the linking stage), I'd rather view
> >> this as an improvement to MAYBE_BUILD_BUG_ON() (which should
> >> then be used here).
> >
> >Can you be more specific?
> >
> >I have no idea what Rusty suggested where. I can't even guess what
>
> I'm attaching Rusty's response I was referring to.
>
> >MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
>
> Agreed - but presumably better than just deleting the bogus instances
> altogether...
>
> Jan
> email message attachment
> > Forwarded Message
> > From: Rusty Russell
> > To: Jan Beulich
> > Cc: linux-ker...@vger.kernel.org
> > Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses
> > of it
> > Date: Wed, 23 Sep 2009 10:27:00 +0930
> >
> > On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
> > > gcc permitting variable length arrays makes the current construct
> > > used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
> > > if the controlling expression isn't really constant. Instead, this
> > > patch makes it so that a bit field gets used here. Consequently, those
> > > uses where the condition isn't really constant now also need fixing.
> > >
> > > Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
> > > MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
> > > if the expression is compile time constant (__builtin_constant_p()
> > > yields true), the array is still deemed of variable length by gcc, and
> > > hence the whole expression doesn't have the intended effect.
> > >
> > > Signed-off-by: Jan Beulich
> >
> > We used to use an undefined symbol here; diagnostics are worse but it
> > catches
> > more stuff.
> >
> > Perhaps a hybrid is the way to go?
> >
> > #ifndef __OPTIMIZE__
> > #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> > #else
> > /* If it's a constant, catch it at compile time, otherwise at link time. */
> > 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
> >
> > Thanks,
> > Rusty.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
>>> Hollis Blanchard 02.10.09 17:48 >>>
>On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
>> The one Rusty suggested the other day may help here. I don't like it
>> as a drop-in replacement for BUILD_BUG_ON() though (due to it
>> deferring the error generated to the linking stage), I'd rather view
>> this as an improvement to MAYBE_BUILD_BUG_ON() (which should
>> then be used here).
>
>Can you be more specific?
>
>I have no idea what Rusty suggested where. I can't even guess what
I'm attaching Rusty's response I was referring to.
>MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
Agreed - but presumably better than just deleting the bogus instances
altogether...
Jan
--- Begin Message ---
On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
> gcc permitting variable length arrays makes the current construct
> used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
> if the controlling expression isn't really constant. Instead, this
> patch makes it so that a bit field gets used here. Consequently, those
> uses where the condition isn't really constant now also need fixing.
>
> Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
> MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
> if the expression is compile time constant (__builtin_constant_p()
> yields true), the array is still deemed of variable length by gcc, and
> hence the whole expression doesn't have the intended effect.
>
> Signed-off-by: Jan Beulich
We used to use an undefined symbol here; diagnostics are worse but it catches
more stuff.
Perhaps a hybrid is the way to go?
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
/* If it's a constant, catch it at compile time, otherwise at link time. */
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
Thanks,
Rusty.
--- End Message ---
Re: linux-next: tree build failure
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote: > >>> Hollis Blanchard 30.09.09 01:39 >>> > >On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote: > >> >>> Hollis Blanchard 09/29/09 2:00 AM >>> > >> >First, I think there is a real bug here, and the code should read like > >> >this (to match the comment): > >> >/* type has to be known at build time for optimization */ > >> >-BUILD_BUG_ON(__builtin_constant_p(type)); > >> >+BUILD_BUG_ON(!__builtin_constant_p(type)); > >> > > >> >However, I get the same build error *both* ways, i.e. > >> >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or > >> >the new BUILD_BUG_ON() macro isn't working... > >> > >> No, at this point of the compilation process it's neither zero nor one, > >> it's simply considered non-constant by the compiler at that stage > >> (this builtin is used for optimization, not during parsing, and the > >> error gets generated when the body of the function gets parsed, > >> not when code gets generated from it). > > > >I think I see what you're saying. Do you have a fix to suggest? > > The one Rusty suggested the other day may help here. I don't like it > as a drop-in replacement for BUILD_BUG_ON() though (due to it > deferring the error generated to the linking stage), I'd rather view > this as an improvement to MAYBE_BUILD_BUG_ON() (which should > then be used here). Can you be more specific? I have no idea what Rusty suggested where. I can't even guess what MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name). All I know is that this used to build... -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
>>> Hollis Blanchard 30.09.09 01:39 >>> >On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote: >> >>> Hollis Blanchard 09/29/09 2:00 AM >>> >> >First, I think there is a real bug here, and the code should read like >> >this (to match the comment): >> >/* type has to be known at build time for optimization */ >> >-BUILD_BUG_ON(__builtin_constant_p(type)); >> >+BUILD_BUG_ON(!__builtin_constant_p(type)); >> > >> >However, I get the same build error *both* ways, i.e. >> >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or >> >the new BUILD_BUG_ON() macro isn't working... >> >> No, at this point of the compilation process it's neither zero nor one, >> it's simply considered non-constant by the compiler at that stage >> (this builtin is used for optimization, not during parsing, and the >> error gets generated when the body of the function gets parsed, >> not when code gets generated from it). > >I think I see what you're saying. Do you have a fix to suggest? The one Rusty suggested the other day may help here. I don't like it as a drop-in replacement for BUILD_BUG_ON() though (due to it deferring the error generated to the linking stage), I'd rather view this as an improvement to MAYBE_BUILD_BUG_ON() (which should then be used here). Jan -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
>>> roel kluin 29.09.09 11:51 >>> >On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich wrote: > Hollis Blanchard 09/29/09 2:00 AM >>> >>>First, I think there is a real bug here, and the code should read like >>>this (to match the comment): >>>/* type has to be known at build time for optimization */ >>>-BUILD_BUG_ON(__builtin_constant_p(type)); >>>+BUILD_BUG_ON(!__builtin_constant_p(type)); >>> >>>However, I get the same build error *both* ways, i.e. >>>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or >>>the new BUILD_BUG_ON() macro isn't working... >> >> No, at this point of the compilation process it's neither zero nor one, >> it's simply considered non-constant by the compiler at that stage >> (this builtin is used for optimization, not during parsing, and the >> error gets generated when the body of the function gets parsed, >> not when code gets generated from it). >> >> Jan > >then maybe > >if(__builtin_constant_p(type)) >BUILD_BUG_ON(1); > >would work? Definitely not - this would result in the compiler *always* generating an error. Jan -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote: > >>> Hollis Blanchard 09/29/09 2:00 AM >>> > >First, I think there is a real bug here, and the code should read like > >this (to match the comment): > >/* type has to be known at build time for optimization */ > >-BUILD_BUG_ON(__builtin_constant_p(type)); > >+BUILD_BUG_ON(!__builtin_constant_p(type)); > > > >However, I get the same build error *both* ways, i.e. > >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or > >the new BUILD_BUG_ON() macro isn't working... > > No, at this point of the compilation process it's neither zero nor one, > it's simply considered non-constant by the compiler at that stage > (this builtin is used for optimization, not during parsing, and the > error gets generated when the body of the function gets parsed, > not when code gets generated from it). I think I see what you're saying. Do you have a fix to suggest? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich wrote: Hollis Blanchard 09/29/09 2:00 AM >>> >>First, I think there is a real bug here, and the code should read like >>this (to match the comment): >> /* type has to be known at build time for optimization */ >>- BUILD_BUG_ON(__builtin_constant_p(type)); >>+ BUILD_BUG_ON(!__builtin_constant_p(type)); >> >>However, I get the same build error *both* ways, i.e. >>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or >>the new BUILD_BUG_ON() macro isn't working... > > No, at this point of the compilation process it's neither zero nor one, > it's simply considered non-constant by the compiler at that stage > (this builtin is used for optimization, not during parsing, and the > error gets generated when the body of the function gets parsed, > not when code gets generated from it). > > Jan then maybe if(__builtin_constant_p(type)) BUILD_BUG_ON(1); would work? Roel -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
>>> Hollis Blanchard 09/29/09 2:00 AM >>> >First, I think there is a real bug here, and the code should read like >this (to match the comment): >/* type has to be known at build time for optimization */ >-BUILD_BUG_ON(__builtin_constant_p(type)); >+BUILD_BUG_ON(!__builtin_constant_p(type)); > >However, I get the same build error *both* ways, i.e. >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or >the new BUILD_BUG_ON() macro isn't working... No, at this point of the compilation process it's neither zero nor one, it's simply considered non-constant by the compiler at that stage (this builtin is used for optimization, not during parsing, and the error gets generated when the body of the function gets parsed, not when code gets generated from it). Jan -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: tree build failure
On Thu, 2009-09-24 at 15:21 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> In file included from arch/powerpc/kvm/booke.c:31:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '' width not an
> integer constant
> In file included from arch/powerpc/kvm/booke.h:26,
> from arch/powerpc/kvm/booke_emulate.c:23:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '' width not an
> integer constant
>
> Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
> ("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ BUILD_BUG_ON(!__builtin_constant_p(type));
However, I get the same build error *both* ways, i.e.
__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
the new BUILD_BUG_ON() macro isn't working...
> I applied the following patch for today. This inline function is
> only called from one place in one file ...
It's also called via kvmppc_account_exit() from a number of places.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: tree build failure
Hi all,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
In file included from arch/powerpc/kvm/booke.c:31:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '' width not an
integer constant
In file included from arch/powerpc/kvm/booke.h:26,
from arch/powerpc/kvm/booke_emulate.c:23:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '' width not an
integer constant
Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
I applied the following patch for today. This inline function is
only called from one place in one file ...
From: Stephen Rothwell
Date: Thu, 24 Sep 2009 15:13:20 +1000
Subject: [PATCH] powerpc/kvm: build fix for new BUILD_BUG_ON
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kvm/timing.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
index bb13b1f..4c34099 100644
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@ -48,7 +48,7 @@ static inline void kvmppc_set_exit_type(struct kvm_vcpu
*vcpu, int type) {}
static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
{
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ //BUILD_BUG_ON(__builtin_constant_p(type));
switch (type) {
case EXT_INTR_EXITS:
vcpu->stat.ext_intr_exits++;
--
1.6.4.3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
