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
>>> 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
>>> 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
>>> 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
