* Re: linux-next: tree build failure
@ 2009-09-29 9:28 ` Jan Beulich
0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw)
To: sfr, hollisb; +Cc: akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next
>>> 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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:28 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw) To: sfr, hollisb; +Cc: akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next >>> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:28 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw) To: sfr, hollisb; +Cc: akpm, linux-next, linuxppc-dev, linux-kernel, kvm-ppc >>> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:28 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw) To: sfr, hollisb; +Cc: akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next >>> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:51 ` roel kluin 0 siblings, 0 replies; 97+ messages in thread From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw) To: Jan Beulich Cc: sfr, hollisb, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:51 ` roel kluin 0 siblings, 0 replies; 97+ messages in thread From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw) To: Jan Beulich Cc: sfr, hollisb, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:51 ` roel kluin 0 siblings, 0 replies; 97+ messages in thread From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw) To: Jan Beulich Cc: sfr, hollisb, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> wrote: >>>> Hollis Blanchard =A009/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): >> =A0 =A0/* type has to be known at build time for optimization */ >>- =A0 =A0BUILD_BUG_ON(__builtin_constant_p(type)); >>+ =A0 =A0BUILD_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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 9:51 ` roel kluin 0 siblings, 0 replies; 97+ messages in thread From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw) To: Jan Beulich Cc: sfr-3FnU+UHB4dNDw9hX6IcOSA, hollisb-r/Jw6+rmf7HQT0dZR+AlfA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:29 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:29 UTC (permalink / raw) To: roel kluin Cc: sfr, akpm, linuxppc-dev, hollisb, kvm-ppc, linux-kernel, linux-next >>> roel kluin <roel.kluin@gmail.com> 29.09.09 11:51 >>> >On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:29 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:29 UTC (permalink / raw) To: roel kluin Cc: sfr, akpm, linuxppc-dev, hollisb, kvm-ppc, linux-kernel, linux-next >>> roel kluin <roel.kluin@gmail.com> 29.09.09 11:51 >>> >On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:29 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:29 UTC (permalink / raw) To: roel kluin Cc: sfr, hollisb, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev >>> roel kluin <roel.kluin@gmail.com> 29.09.09 11:51 >>> >On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> = 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:29 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:29 UTC (permalink / raw) To: roel kluin Cc: sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, hollisb-r/Jw6+rmf7HQT0dZR+AlfA, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA >>> roel kluin <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 29.09.09 11:51 >>> >On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 23:39 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 23:39 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 23:39 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 23:39 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 23:39 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 23:39 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 23:39 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 23:39 UTC (permalink / raw) To: Jan Beulich Cc: sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:35 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:35 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:35 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:35 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:35 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:35 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev >>> Hollis Blanchard <hollisb@us.ibm.com> 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... >>=20 >> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-30 6:35 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-09-30 6:35 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA >>> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-02 15:48 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-02 15:48 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-02 15:48 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-02 15:48 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-02 15:48 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-02 15:48 UTC (permalink / raw) To: Jan Beulich; +Cc: sfr, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-02 15:48 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-02 15:48 UTC (permalink / raw) To: Jan Beulich Cc: sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-02 15:48 ` Hollis Blanchard (?) (?) @ 2009-10-05 6:58 ` Jan Beulich -1 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-05 6:58 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 745 bytes --] >>> Hollis Blanchard <hollisb@us.ibm.com> 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 [-- Attachment #2: Type: message/rfc822, Size: 2578 bytes --] From: Rusty Russell <rusty@rustcorp.com.au> To: "Jan Beulich" <JBeulich@novell.com> Cc: linux-kernel@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 Message-ID: <200909231027.01006.rusty@rustcorp.com.au> 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 <jbeulich@novell.com> 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-05 6:58 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-05 6:58 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 745 bytes --] >>> Hollis Blanchard <hollisb@us.ibm.com> 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 [-- Attachment #2: Type: message/rfc822, Size: 2578 bytes --] From: Rusty Russell <rusty@rustcorp.com.au> To: "Jan Beulich" <JBeulich@novell.com> Cc: linux-kernel@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 Message-ID: <200909231027.01006.rusty@rustcorp.com.au> 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 <jbeulich@novell.com> 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-05 6:58 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-05 6:58 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 745 bytes --] >>> Hollis Blanchard <hollisb@us.ibm.com> 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 [-- Attachment #2: Type: message/rfc822, Size: 2578 bytes --] From: Rusty Russell <rusty@rustcorp.com.au> To: "Jan Beulich" <JBeulich@novell.com> Cc: linux-kernel@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 Message-ID: <200909231027.01006.rusty@rustcorp.com.au> 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 <jbeulich@novell.com> 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-05 6:58 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-05 6:58 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 745 bytes --] >>> Hollis Blanchard <hollisb@us.ibm.com> 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 [-- Attachment #2: Type: message/rfc822, Size: 2578 bytes --] From: Rusty Russell <rusty@rustcorp.com.au> To: "Jan Beulich" <JBeulich@novell.com> Cc: linux-kernel@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 Message-ID: <200909231027.01006.rusty@rustcorp.com.au> 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 <jbeulich@novell.com> 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. [-- Attachment #3: Type: text/plain, Size: 150 bytes --] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-05 6:58 ` Jan Beulich (?) @ 2009-10-09 19:14 ` Hollis Blanchard -1 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-09 19:14 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next 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 <hollisb@us.ibm.com> 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 <rusty@rustcorp.com.au> > > To: Jan Beulich <JBeulich@novell.com> > > Cc: linux-kernel@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 <jbeulich@novell.com> > > > > 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-09 19:14 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-09 19:14 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next 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 <hollisb@us.ibm.com> 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 <rusty@rustcorp.com.au> > > To: Jan Beulich <JBeulich@novell.com> > > Cc: linux-kernel@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 <jbeulich@novell.com> > > > > 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-09 19:14 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-09 19:14 UTC (permalink / raw) To: Jan Beulich Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev 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 <hollisb@us.ibm.com> 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 <rusty@rustcorp.com.au> > > To: Jan Beulich <JBeulich@novell.com> > > Cc: linux-kernel@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 <jbeulich@novell.com> > > > > 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-09 19:14 ` Hollis Blanchard (?) @ 2009-10-14 22:57 ` Hollis Blanchard -1 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-14 22:57 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-14 22:57 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-14 22:57 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-14 22:57 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-14 22:57 UTC (permalink / raw) To: Jan Beulich Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-14 22:57 ` Hollis Blanchard (?) (?) @ 2009-10-15 7:27 ` Jan Beulich -1 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-15 7:27 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-15 7:27 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-15 7:27 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-15 7:27 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-15 7:27 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev >>> Hollis Blanchard <hollisb@us.ibm.com> 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: >>=20 >> original: built but didn't work >> Jan's: doesn't build >> Rusty's: builds and works >>=20 >> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-15 7:27 ` Jan Beulich 0 siblings, 0 replies; 97+ messages in thread From: Jan Beulich @ 2009-10-15 7:27 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-15 7:27 ` Jan Beulich (?) @ 2009-10-19 18:19 ` Hollis Blanchard -1 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-19 18:19 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-19 18:19 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-19 18:19 UTC (permalink / raw) To: Jan Beulich Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel, linux-next On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-19 18:19 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-19 18:19 UTC (permalink / raw) To: Jan Beulich Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm, linuxppc-dev On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: > >>> Hollis Blanchard <hollisb@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure 2009-10-19 18:19 ` Hollis Blanchard (?) @ 2009-10-20 1:12 ` Rusty Russell -1 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 1:12 UTC (permalink / raw) To: Hollis Blanchard Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:12 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 1:24 UTC (permalink / raw) To: Hollis Blanchard Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:12 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 1:12 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev 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. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:29 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:29 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:29 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw) To: Rusty Russell Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-10-20 1:29 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* [PATCH] BUILD_BUG_ON: make it handle more cases 2009-10-20 1:29 ` Hollis Blanchard (?) (?) @ 2009-10-20 3:45 ` Rusty Russell -1 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 3:45 UTC (permalink / raw) To: Hollis Blanchard Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next BUILD_BUG_ON used to use the optimizer to do code elimination or fail at link time; it was changed to first the size of a negative array (a nicer compile time error), then (in 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. bitfields: needs a literal constant at parse time, and can't be put under "if (__builtin_constant_p(x))" for example. negative array: can handle anything, but if the compiler can't tell it's a constant, silently has no effect. link time: breaks link if the compiler can't determine the value, but the linker output is not usually as informative as a compiler error. If we use the negative-array-size method *and* the link time trick, we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() branches, and maximal ability for the compiler to detect errors at build time. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff --git a/include/linux/kernel.h b/include/linux/kernel.h --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -683,12 +683,6 @@ 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 @@ -696,6 +690,33 @@ struct sysinfo { #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 +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) + /* Trap pasters of __FUNCTION__ at compile-time */ #define __FUNCTION__ (__func__) ^ permalink raw reply [flat|nested] 97+ messages in thread
* [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 3:45 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 3:57 UTC (permalink / raw) To: Hollis Blanchard Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next BUILD_BUG_ON used to use the optimizer to do code elimination or fail at link time; it was changed to first the size of a negative array (a nicer compile time error), then (in 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. bitfields: needs a literal constant at parse time, and can't be put under "if (__builtin_constant_p(x))" for example. negative array: can handle anything, but if the compiler can't tell it's a constant, silently has no effect. link time: breaks link if the compiler can't determine the value, but the linker output is not usually as informative as a compiler error. If we use the negative-array-size method *and* the link time trick, we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() branches, and maximal ability for the compiler to detect errors at build time. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff --git a/include/linux/kernel.h b/include/linux/kernel.h --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -683,12 +683,6 @@ 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 @@ -696,6 +690,33 @@ struct sysinfo { #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 +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) + /* Trap pasters of __FUNCTION__ at compile-time */ #define __FUNCTION__ (__func__) ^ permalink raw reply [flat|nested] 97+ messages in thread
* [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 3:45 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 3:45 UTC (permalink / raw) To: Hollis Blanchard Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev BUILD_BUG_ON used to use the optimizer to do code elimination or fail at link time; it was changed to first the size of a negative array (a nicer compile time error), then (in 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. bitfields: needs a literal constant at parse time, and can't be put under "if (__builtin_constant_p(x))" for example. negative array: can handle anything, but if the compiler can't tell it's a constant, silently has no effect. link time: breaks link if the compiler can't determine the value, but the linker output is not usually as informative as a compiler error. If we use the negative-array-size method *and* the link time trick, we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() branches, and maximal ability for the compiler to detect errors at build time. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff --git a/include/linux/kernel.h b/include/linux/kernel.h --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -683,12 +683,6 @@ 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 @@ -696,6 +690,33 @@ struct sysinfo { #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 +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) + /* Trap pasters of __FUNCTION__ at compile-time */ #define __FUNCTION__ (__func__) ^ permalink raw reply [flat|nested] 97+ messages in thread
* [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 3:45 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-10-20 3:45 UTC (permalink / raw) To: Hollis Blanchard Cc: Jan Beulich, sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA BUILD_BUG_ON used to use the optimizer to do code elimination or fail at link time; it was changed to first the size of a negative array (a nicer compile time error), then (in 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. bitfields: needs a literal constant at parse time, and can't be put under "if (__builtin_constant_p(x))" for example. negative array: can handle anything, but if the compiler can't tell it's a constant, silently has no effect. link time: breaks link if the compiler can't determine the value, but the linker output is not usually as informative as a compiler error. If we use the negative-array-size method *and* the link time trick, we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() branches, and maximal ability for the compiler to detect errors at build time. Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> diff --git a/include/linux/kernel.h b/include/linux/kernel.h --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -683,12 +683,6 @@ 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 @@ -696,6 +690,33 @@ struct sysinfo { #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 +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) + /* Trap pasters of __FUNCTION__ at compile-time */ #define __FUNCTION__ (__func__) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-10-20 3:45 ` Rusty Russell (?) @ 2009-10-20 13:58 ` Américo Wang -1 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-20 13:58 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >BUILD_BUG_ON used to use the optimizer to do code elimination or fail >at link time; it was changed to first the size of a negative array (a >nicer compile time error), then (in >8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > >bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. >negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. >link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > >If we use the negative-array-size method *and* the link time trick, >we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >branches, and maximal ability for the compiler to detect errors at >build time. > >Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > >diff --git a/include/linux/kernel.h b/include/linux/kernel.h >--- a/include/linux/kernel.h >+++ b/include/linux/kernel.h >@@ -683,12 +683,6 @@ 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 >@@ -696,6 +690,33 @@ struct sysinfo { > #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; Hmm, what exactly is __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 >+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >+ > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Live like a child, think like the god. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 13:58 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-20 13:58 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >BUILD_BUG_ON used to use the optimizer to do code elimination or fail >at link time; it was changed to first the size of a negative array (a >nicer compile time error), then (in >8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > >bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. >negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. >link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > >If we use the negative-array-size method *and* the link time trick, >we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >branches, and maximal ability for the compiler to detect errors at >build time. > >Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > >diff --git a/include/linux/kernel.h b/include/linux/kernel.h >--- a/include/linux/kernel.h >+++ b/include/linux/kernel.h >@@ -683,12 +683,6 @@ 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 >@@ -696,6 +690,33 @@ struct sysinfo { > #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; Hmm, what exactly is __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 >+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >+ > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Live like a child, think like the god. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 13:58 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-20 13:58 UTC (permalink / raw) To: Rusty Russell Cc: sfr, Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >BUILD_BUG_ON used to use the optimizer to do code elimination or fail >at link time; it was changed to first the size of a negative array (a >nicer compile time error), then (in >8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > >bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. >negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. >link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > >If we use the negative-array-size method *and* the link time trick, >we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >branches, and maximal ability for the compiler to detect errors at >build time. > >Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > >diff --git a/include/linux/kernel.h b/include/linux/kernel.h >--- a/include/linux/kernel.h >+++ b/include/linux/kernel.h >@@ -683,12 +683,6 @@ 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 >@@ -696,6 +690,33 @@ struct sysinfo { > #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; Hmm, what exactly is __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 >+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >+ > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Live like a child, think like the god. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-10-20 13:58 ` Américo Wang (?) @ 2009-10-20 14:43 ` Alan Jenkins -1 siblings, 0 replies; 97+ messages in thread From: Alan Jenkins @ 2009-10-20 14:43 UTC (permalink / raw) To: Américo Wang Cc: Rusty Russell, Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On 10/20/09, Américo Wang <xiyou.wangcong@gmail.com> wrote: > On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>at link time; it was changed to first the size of a negative array (a >>nicer compile time error), then (in >>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >> >>bitfields: needs a literal constant at parse time, and can't be put under >> "if (__builtin_constant_p(x))" for example. >>negative array: can handle anything, but if the compiler can't tell it's >> a constant, silently has no effect. >>link time: breaks link if the compiler can't determine the value, but the >> linker output is not usually as informative as a compiler error. >> >>If we use the negative-array-size method *and* the link time trick, >>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>branches, and maximal ability for the compiler to detect errors at >>build time. >> >>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >> >>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>--- a/include/linux/kernel.h >>+++ b/include/linux/kernel.h >>@@ -683,12 +683,6 @@ 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 >>@@ -696,6 +690,33 @@ struct sysinfo { >> #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; > > Hmm, what exactly is __build_bug_on_failed? Well, we haven't added a definition for it in this patch. I'm sure grep will tell you it wasn't defined before hand either. So any reference to it is an error - which will be reported at link time. >>+#define BUILD_BUG_ON(condition) \ >>+ do { \ >>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>+ if (condition) __build_bug_on_failed = 1; \ If "condition" is known false at compile time, gcc -O will eliminate the code which refers to __build_bug_on_failed. If it's not proved to be false - it will break the build, which is exactly what we want BUILD_BUG_ON to do. >>+ } while(0) >>+#endif >>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >>+ >> /* Trap pasters of __FUNCTION__ at compile-time */ >> #define __FUNCTION__ (__func__) >> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 14:43 ` Alan Jenkins 0 siblings, 0 replies; 97+ messages in thread From: Alan Jenkins @ 2009-10-20 14:43 UTC (permalink / raw) To: Américo Wang Cc: Rusty Russell, Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On 10/20/09, Américo Wang <xiyou.wangcong@gmail.com> wrote: > On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>at link time; it was changed to first the size of a negative array (a >>nicer compile time error), then (in >>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >> >>bitfields: needs a literal constant at parse time, and can't be put under >> "if (__builtin_constant_p(x))" for example. >>negative array: can handle anything, but if the compiler can't tell it's >> a constant, silently has no effect. >>link time: breaks link if the compiler can't determine the value, but the >> linker output is not usually as informative as a compiler error. >> >>If we use the negative-array-size method *and* the link time trick, >>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>branches, and maximal ability for the compiler to detect errors at >>build time. >> >>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >> >>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>--- a/include/linux/kernel.h >>+++ b/include/linux/kernel.h >>@@ -683,12 +683,6 @@ 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 >>@@ -696,6 +690,33 @@ struct sysinfo { >> #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; > > Hmm, what exactly is __build_bug_on_failed? Well, we haven't added a definition for it in this patch. I'm sure grep will tell you it wasn't defined before hand either. So any reference to it is an error - which will be reported at link time. >>+#define BUILD_BUG_ON(condition) \ >>+ do { \ >>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>+ if (condition) __build_bug_on_failed = 1; \ If "condition" is known false at compile time, gcc -O will eliminate the code which refers to __build_bug_on_failed. If it's not proved to be false - it will break the build, which is exactly what we want BUILD_BUG_ON to do. >>+ } while(0) >>+#endif >>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >>+ >> /* Trap pasters of __FUNCTION__ at compile-time */ >> #define __FUNCTION__ (__func__) >> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-20 14:43 ` Alan Jenkins 0 siblings, 0 replies; 97+ messages in thread From: Alan Jenkins @ 2009-10-20 14:43 UTC (permalink / raw) To: Américo Wang Cc: sfr, Hollis Blanchard, Rusty Russell, linux-kernel, Jan Beulich, linux-next, kvm-ppc, akpm, linuxppc-dev On 10/20/09, Am=E9rico Wang <xiyou.wangcong@gmail.com> wrote: > On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>at link time; it was changed to first the size of a negative array (a >>nicer compile time error), then (in >>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >> >>bitfields: needs a literal constant at parse time, and can't be put under >> "if (__builtin_constant_p(x))" for example. >>negative array: can handle anything, but if the compiler can't tell it's >> a constant, silently has no effect. >>link time: breaks link if the compiler can't determine the value, but the >> linker output is not usually as informative as a compiler error. >> >>If we use the negative-array-size method *and* the link time trick, >>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>branches, and maximal ability for the compiler to detect errors at >>build time. >> >>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >> >>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>--- a/include/linux/kernel.h >>+++ b/include/linux/kernel.h >>@@ -683,12 +683,6 @@ 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 >>@@ -696,6 +690,33 @@ struct sysinfo { >> #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 t= o >>+ * 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; > > Hmm, what exactly is __build_bug_on_failed? Well, we haven't added a definition for it in this patch. I'm sure grep will tell you it wasn't defined before hand either. So any reference to it is an error - which will be reported at link time. >>+#define BUILD_BUG_ON(condition) \ >>+ do { \ >>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>+ if (condition) __build_bug_on_failed =3D 1; \ If "condition" is known false at compile time, gcc -O will eliminate the code which refers to __build_bug_on_failed. If it's not proved to be false - it will break the build, which is exactly what we want BUILD_BUG_ON to do. >>+ } while(0) >>+#endif >>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) >>+ >> /* Trap pasters of __FUNCTION__ at compile-time */ >> #define __FUNCTION__ (__func__) >> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-23 1:50 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-23 1:50 UTC (permalink / raw) To: Alan Jenkins Cc: Rusty Russell, Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote: > On 10/20/09, Américo Wang <xiyou.wangcong@gmail.com> wrote: >> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>>at link time; it was changed to first the size of a negative array (a >>>nicer compile time error), then (in >>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >>> >>>bitfields: needs a literal constant at parse time, and can't be put under >>> "if (__builtin_constant_p(x))" for example. >>>negative array: can handle anything, but if the compiler can't tell it's >>> a constant, silently has no effect. >>>link time: breaks link if the compiler can't determine the value, but the >>> linker output is not usually as informative as a compiler error. >>> >>>If we use the negative-array-size method *and* the link time trick, >>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>>branches, and maximal ability for the compiler to detect errors at >>>build time. >>> >>>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >>> >>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>>--- a/include/linux/kernel.h >>>+++ b/include/linux/kernel.h >>>@@ -683,12 +683,6 @@ 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 >>>@@ -696,6 +690,33 @@ struct sysinfo { >>> #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; >> >> Hmm, what exactly is __build_bug_on_failed? > > Well, we haven't added a definition for it in this patch. I'm sure > grep will tell you it wasn't defined before hand either. So any > reference to it is an error - which will be reported at link time. > >>>+#define BUILD_BUG_ON(condition) \ >>>+ do { \ >>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>>+ if (condition) __build_bug_on_failed = 1; \ > > If "condition" is known false at compile time, gcc -O will eliminate > the code which refers to __build_bug_on_failed. If it's not proved to > be false - it will break the build, which is exactly what we want > BUILD_BUG_ON to do. Ah, clever trick! Got it. Thanks! Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-23 1:50 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-23 1:50 UTC (permalink / raw) To: Alan Jenkins Cc: Rusty Russell, Hollis Blanchard, Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote: > On 10/20/09, Américo Wang <xiyou.wangcong@gmail.com> wrote: >> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>>at link time; it was changed to first the size of a negative array (a >>>nicer compile time error), then (in >>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >>> >>>bitfields: needs a literal constant at parse time, and can't be put under >>> "if (__builtin_constant_p(x))" for example. >>>negative array: can handle anything, but if the compiler can't tell it's >>> a constant, silently has no effect. >>>link time: breaks link if the compiler can't determine the value, but the >>> linker output is not usually as informative as a compiler error. >>> >>>If we use the negative-array-size method *and* the link time trick, >>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>>branches, and maximal ability for the compiler to detect errors at >>>build time. >>> >>>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >>> >>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>>--- a/include/linux/kernel.h >>>+++ b/include/linux/kernel.h >>>@@ -683,12 +683,6 @@ 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 >>>@@ -696,6 +690,33 @@ struct sysinfo { >>> #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; >> >> Hmm, what exactly is __build_bug_on_failed? > > Well, we haven't added a definition for it in this patch. I'm sure > grep will tell you it wasn't defined before hand either. So any > reference to it is an error - which will be reported at link time. > >>>+#define BUILD_BUG_ON(condition) \ >>>+ do { \ >>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>>+ if (condition) __build_bug_on_failed = 1; \ > > If "condition" is known false at compile time, gcc -O will eliminate > the code which refers to __build_bug_on_failed. If it's not proved to > be false - it will break the build, which is exactly what we want > BUILD_BUG_ON to do. Ah, clever trick! Got it. Thanks! Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-23 1:50 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-23 1:50 UTC (permalink / raw) To: Alan Jenkins Cc: sfr, Hollis Blanchard, Rusty Russell, linux-kernel, Jan Beulich, linux-next, kvm-ppc, akpm, linuxppc-dev On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote: > On 10/20/09, Am=C3=A9rico Wang <xiyou.wangcong@gmail.com> wrote: >> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>>at link time; it was changed to first the size of a negative array (a >>>nicer compile time error), then (in >>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >>> >>>bitfields: needs a literal constant at parse time, and can't be put unde= r >>> =C2=A0 =C2=A0 =C2=A0"if (__builtin_constant_p(x))" for example. >>>negative array: can handle anything, but if the compiler can't tell it's >>> =C2=A0 =C2=A0 =C2=A0a constant, silently has no effect. >>>link time: breaks link if the compiler can't determine the value, but th= e >>> =C2=A0 =C2=A0 =C2=A0linker output is not usually as informative as a co= mpiler error. >>> >>>If we use the negative-array-size method *and* the link time trick, >>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>>branches, and maximal ability for the compiler to detect errors at >>>build time. >>> >>>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >>> >>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>>--- a/include/linux/kernel.h >>>+++ b/include/linux/kernel.h >>>@@ -683,12 +683,6 @@ struct sysinfo { >>> =C2=A0 =C2=A0 =C2=A0char _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 >>> =C2=A0 =C2=A0result (of value 0 and type size_t), so the expression can= be used >>> =C2=A0 =C2=A0e.g. in a structure initializer (or where-ever else comma = expressions >>>@@ -696,6 +690,33 @@ struct sysinfo { >>> #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). =C2=A0So as a fallback we use the optimizer; i= f it >>> can't >>>+ * prove the condition is false, it will cause a link error on the >>> undefined >>>+ * "__build_bug_on_failed". =C2=A0This error message can be harder to t= rack >>> 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; >> >> Hmm, what exactly is __build_bug_on_failed? > > Well, we haven't added a definition for it in this patch. =C2=A0I'm sure > grep will tell you it wasn't defined before hand either. =C2=A0So any > reference to it is an error - which will be reported at link time. > >>>+#define BUILD_BUG_ON(condition) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0\ >>>+ =C2=A0 =C2=A0 do { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ >>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((void)sizeof(char[1 - 2*!!(= condition)])); =C2=A0 =C2=A0 =C2=A0\ >>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (condition) __build_bug_o= n_failed =3D 1; =C2=A0 =C2=A0 =C2=A0 \ > > If "condition" is known false at compile time, gcc -O will eliminate > the code which refers to __build_bug_on_failed. =C2=A0If it's not proved = to > be false - it will break the build, which is exactly what we want > BUILD_BUG_ON to do. Ah, clever trick! Got it. Thanks! Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-23 1:50 ` Américo Wang 0 siblings, 0 replies; 97+ messages in thread From: Américo Wang @ 2009-10-23 1:50 UTC (permalink / raw) To: Alan Jenkins Cc: Rusty Russell, Hollis Blanchard, Jan Beulich, sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins <sourcejedi.lkml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > On 10/20/09, Américo Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote: >>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail >>>at link time; it was changed to first the size of a negative array (a >>>nicer compile time error), then (in >>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. >>> >>>bitfields: needs a literal constant at parse time, and can't be put under >>> "if (__builtin_constant_p(x))" for example. >>>negative array: can handle anything, but if the compiler can't tell it's >>> a constant, silently has no effect. >>>link time: breaks link if the compiler can't determine the value, but the >>> linker output is not usually as informative as a compiler error. >>> >>>If we use the negative-array-size method *and* the link time trick, >>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() >>>branches, and maximal ability for the compiler to detect errors at >>>build time. >>> >>>Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> >>> >>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h >>>--- a/include/linux/kernel.h >>>+++ b/include/linux/kernel.h >>>@@ -683,12 +683,6 @@ 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 >>>@@ -696,6 +690,33 @@ struct sysinfo { >>> #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; >> >> Hmm, what exactly is __build_bug_on_failed? > > Well, we haven't added a definition for it in this patch. I'm sure > grep will tell you it wasn't defined before hand either. So any > reference to it is an error - which will be reported at link time. > >>>+#define BUILD_BUG_ON(condition) \ >>>+ do { \ >>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \ >>>+ if (condition) __build_bug_on_failed = 1; \ > > If "condition" is known false at compile time, gcc -O will eliminate > the code which refers to __build_bug_on_failed. If it's not proved to > be false - it will break the build, which is exactly what we want > BUILD_BUG_ON to do. Ah, clever trick! Got it. Thanks! Reviewed-by: WANG Cong <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-22 21:04 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-22 21:04 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Thanks Rusty, this indeed fixes the problem. Acked-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-22 21:04 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-22 21:04 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Thanks Rusty, this indeed fixes the problem. Acked-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-22 21:04 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-22 21:04 UTC (permalink / raw) To: Rusty Russell Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Thanks Rusty, this indeed fixes the problem. Acked-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-22 21:04 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-22 21:04 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr-3FnU+UHB4dNDw9hX6IcOSA, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> Thanks Rusty, this indeed fixes the problem. Acked-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-10-20 3:45 ` Rusty Russell (?) @ 2009-10-29 21:30 ` Hollis Blanchard -1 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-29 21:30 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) What's the state of this patch? -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-29 21:30 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-29 21:30 UTC (permalink / raw) To: Rusty Russell Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) What's the state of this patch? -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-10-29 21:30 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-10-29 21:30 UTC (permalink / raw) To: Rusty Russell Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) What's the state of this patch? -- Hollis Blanchard IBM Linux Technology Center ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 0:20 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 0:20 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Hi Rusty, On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > +#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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + I decided to try this in linux-next, but an x86_64 allmodconfig build gave this (gcc 4.4.0): ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in virtio_has_feature() (in include/linux/virtio_config.h) which is called all over the place. Unfortunately, virtio_has_feature() gets uninlined in those two files ... I have taken the patch back out again for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 0:20 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 0:20 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Hi Rusty, On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > +#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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + I decided to try this in linux-next, but an x86_64 allmodconfig build gave this (gcc 4.4.0): ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in virtio_has_feature() (in include/linux/virtio_config.h) which is called all over the place. Unfortunately, virtio_has_feature() gets uninlined in those two files ... I have taken the patch back out again for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 0:20 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 0:20 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Hi Rusty, On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > +#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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + I decided to try this in linux-next, but an x86_64 allmodconfig build gave this (gcc 4.4.0): ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in virtio_has_feature() (in include/linux/virtio_config.h) which is called all over the place. Unfortunately, virtio_has_feature() gets uninlined in those two files ... I have taken the patch back out again for today. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 0:20 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 0:20 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 1201 bytes --] Hi Rusty, On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote: > > +#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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + I decided to try this in linux-next, but an x86_64 allmodconfig build gave this (gcc 4.4.0): ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in virtio_has_feature() (in include/linux/virtio_config.h) which is called all over the place. Unfortunately, virtio_has_feature() gets uninlined in those two files ... I have taken the patch back out again for today. -- Cheers, Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-11-05 0:20 ` Stephen Rothwell (?) @ 2009-11-05 6:28 ` Rusty Russell -1 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:28 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 10:50:20 am Stephen Rothwell wrote: > Hi Rusty, > > On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > +#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 > > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > > + > > I decided to try this in linux-next, but an x86_64 allmodconfig build > gave this (gcc 4.4.0): > > ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! > ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! > > I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in > virtio_has_feature() (in include/linux/virtio_config.h) which is called > all over the place. Unfortunately, virtio_has_feature() gets uninlined > in those two files ... Huh? virtio_has_feature does: if (__builtin_constant_p(fbit)) BUILD_BUG_ON(fbit >= 32); else BUG_ON(fbit >= 32); So, if it's not a constant, gcc should throw away that first branch. If it is, it should optimize it away (and no, these are not real bugs AFAICT). I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all was fine. Will try 4.4.0 now. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:28 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:40 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 10:50:20 am Stephen Rothwell wrote: > Hi Rusty, > > On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > +#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 > > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > > + > > I decided to try this in linux-next, but an x86_64 allmodconfig build > gave this (gcc 4.4.0): > > ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! > ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! > > I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in > virtio_has_feature() (in include/linux/virtio_config.h) which is called > all over the place. Unfortunately, virtio_has_feature() gets uninlined > in those two files ... Huh? virtio_has_feature does: if (__builtin_constant_p(fbit)) BUILD_BUG_ON(fbit >= 32); else BUG_ON(fbit >= 32); So, if it's not a constant, gcc should throw away that first branch. If it is, it should optimize it away (and no, these are not real bugs AFAICT). I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all was fine. Will try 4.4.0 now. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:28 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:28 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Thu, 5 Nov 2009 10:50:20 am Stephen Rothwell wrote: > Hi Rusty, > > On Tue, 20 Oct 2009 14:15:33 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > +#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 > > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > > + > > I decided to try this in linux-next, but an x86_64 allmodconfig build > gave this (gcc 4.4.0): > > ERROR: "__build_bug_on_failed" [drivers/net/virtio_net.ko] undefined! > ERROR: "__build_bug_on_failed" [drivers/block/virtio_blk.ko] undefined! > > I assume that this is caused by the "MAYBE_BUILD_BUG_ON(fbit >= 32)" in > virtio_has_feature() (in include/linux/virtio_config.h) which is called > all over the place. Unfortunately, virtio_has_feature() gets uninlined > in those two files ... Huh? virtio_has_feature does: if (__builtin_constant_p(fbit)) BUILD_BUG_ON(fbit >= 32); else BUG_ON(fbit >= 32); So, if it's not a constant, gcc should throw away that first branch. If it is, it should optimize it away (and no, these are not real bugs AFAICT). I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all was fine. Will try 4.4.0 now. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:37 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:37 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 04:58:36 pm Rusty Russell wrote: > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4.1 seems OK (Ubuntu). This is annoying. But I'll withdraw the patches; if there's another reason that 4.4.0 is bad, we can ban it and reintroduce this. I don't think that breaking this hack is enough to declare 4.4.0 verboten. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:37 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:49 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 04:58:36 pm Rusty Russell wrote: > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4.1 seems OK (Ubuntu). This is annoying. But I'll withdraw the patches; if there's another reason that 4.4.0 is bad, we can ban it and reintroduce this. I don't think that breaking this hack is enough to declare 4.4.0 verboten. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:37 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:37 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Thu, 5 Nov 2009 04:58:36 pm Rusty Russell wrote: > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4.1 seems OK (Ubuntu). This is annoying. But I'll withdraw the patches; if there's another reason that 4.4.0 is bad, we can ban it and reintroduce this. I don't think that breaking this hack is enough to declare 4.4.0 verboten. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:37 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-05 6:37 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Thu, 5 Nov 2009 04:58:36 pm Rusty Russell wrote: > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4.1 seems OK (Ubuntu). This is annoying. But I'll withdraw the patches; if there's another reason that 4.4.0 is bad, we can ban it and reintroduce this. I don't think that breaking this hack is enough to declare 4.4.0 verboten. Thanks, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-11-05 6:28 ` Rusty Russell (?) @ 2009-11-05 6:38 ` Stephen Rothwell -1 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 6:38 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 1149 bytes --] Hi Rusty, On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > Huh? virtio_has_feature does: > > if (__builtin_constant_p(fbit)) > BUILD_BUG_ON(fbit >= 32); > else > BUG_ON(fbit >= 32); In Linus' tree (and linux-next) it looks like this: static inline bool virtio_has_feature(const struct virtio_device *vdev, unsigned int fbit) { /* Did you forget to fix assumptions on max features? */ MAYBE_BUILD_BUG_ON(fbit >= 32); if (fbit < VIRTIO_TRANSPORT_F_START) virtio_check_driver_offered_feature(vdev, fbit); return test_bit(fbit, vdev->features); } > So, if it's not a constant, gcc should throw away that first branch. If it > is, it should optimize it away (and no, these are not real bugs AFAICT). Your version above may well fix the problem. Alternatively marking it __always_inline way work as well. > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4 is more problematic. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:38 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 6:38 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next [-- Attachment #1: Type: text/plain, Size: 1149 bytes --] Hi Rusty, On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > Huh? virtio_has_feature does: > > if (__builtin_constant_p(fbit)) > BUILD_BUG_ON(fbit >= 32); > else > BUG_ON(fbit >= 32); In Linus' tree (and linux-next) it looks like this: static inline bool virtio_has_feature(const struct virtio_device *vdev, unsigned int fbit) { /* Did you forget to fix assumptions on max features? */ MAYBE_BUILD_BUG_ON(fbit >= 32); if (fbit < VIRTIO_TRANSPORT_F_START) virtio_check_driver_offered_feature(vdev, fbit); return test_bit(fbit, vdev->features); } > So, if it's not a constant, gcc should throw away that first branch. If it > is, it should optimize it away (and no, these are not real bugs AFAICT). Your version above may well fix the problem. Alternatively marking it __always_inline way work as well. > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4 is more problematic. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:38 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-11-05 6:38 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1149 bytes --] Hi Rusty, On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > Huh? virtio_has_feature does: > > if (__builtin_constant_p(fbit)) > BUILD_BUG_ON(fbit >= 32); > else > BUG_ON(fbit >= 32); In Linus' tree (and linux-next) it looks like this: static inline bool virtio_has_feature(const struct virtio_device *vdev, unsigned int fbit) { /* Did you forget to fix assumptions on max features? */ MAYBE_BUILD_BUG_ON(fbit >= 32); if (fbit < VIRTIO_TRANSPORT_F_START) virtio_check_driver_offered_feature(vdev, fbit); return test_bit(fbit, vdev->features); } > So, if it's not a constant, gcc should throw away that first branch. If it > is, it should optimize it away (and no, these are not real bugs AFAICT). Your version above may well fix the problem. Alternatively marking it __always_inline way work as well. > I did a 4.3.3 allmodconfig with this patch on 64-bit a few days back and all > was fine. Will try 4.4.0 now. 4.4 is more problematic. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-06 6:30 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-06 6:30 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 05:08:42 pm Stephen Rothwell wrote: > Hi Rusty, > > On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > Huh? virtio_has_feature does: > > > > if (__builtin_constant_p(fbit)) > > BUILD_BUG_ON(fbit >= 32); > > else > > BUG_ON(fbit >= 32); > > In Linus' tree (and linux-next) it looks like this: Ah. My patch series fixes that as part of removing MAYBE_BUILD_BUG_ON. I've put both in for linux-next. Cheers, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-06 6:30 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-06 6:42 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next On Thu, 5 Nov 2009 05:08:42 pm Stephen Rothwell wrote: > Hi Rusty, > > On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > Huh? virtio_has_feature does: > > > > if (__builtin_constant_p(fbit)) > > BUILD_BUG_ON(fbit >= 32); > > else > > BUG_ON(fbit >= 32); > > In Linus' tree (and linux-next) it looks like this: Ah. My patch series fixes that as part of removing MAYBE_BUILD_BUG_ON. I've put both in for linux-next. Cheers, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-06 6:30 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-06 6:30 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Thu, 5 Nov 2009 05:08:42 pm Stephen Rothwell wrote: > Hi Rusty, > > On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > Huh? virtio_has_feature does: > > > > if (__builtin_constant_p(fbit)) > > BUILD_BUG_ON(fbit >= 32); > > else > > BUG_ON(fbit >= 32); > > In Linus' tree (and linux-next) it looks like this: Ah. My patch series fixes that as part of removing MAYBE_BUILD_BUG_ON. I've put both in for linux-next. Cheers, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-06 6:30 ` Rusty Russell 0 siblings, 0 replies; 97+ messages in thread From: Rusty Russell @ 2009-11-06 6:30 UTC (permalink / raw) To: Stephen Rothwell Cc: Hollis Blanchard, Jan Beulich, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, kvm-ppc-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA On Thu, 5 Nov 2009 05:08:42 pm Stephen Rothwell wrote: > Hi Rusty, > > On Thu, 5 Nov 2009 16:58:36 +1030 Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote: > > > > Huh? virtio_has_feature does: > > > > if (__builtin_constant_p(fbit)) > > BUILD_BUG_ON(fbit >= 32); > > else > > BUG_ON(fbit >= 32); > > In Linus' tree (and linux-next) it looks like this: Ah. My patch series fixes that as part of removing MAYBE_BUILD_BUG_ON. I've put both in for linux-next. Cheers, Rusty. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases 2009-10-20 3:45 ` Rusty Russell (?) @ 2009-11-05 6:01 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 97+ messages in thread From: Benjamin Herrenschmidt @ 2009-11-05 6:01 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. What's the status with this patch ? The lack of it breaks my KVM stuff in powerpc... Cheers, Ben. > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:01 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 97+ messages in thread From: Benjamin Herrenschmidt @ 2009-11-05 6:01 UTC (permalink / raw) To: Rusty Russell Cc: Hollis Blanchard, sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. What's the status with this patch ? The lack of it breaks my KVM stuff in powerpc... Cheers, Ben. > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases @ 2009-11-05 6:01 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 97+ messages in thread From: Benjamin Herrenschmidt @ 2009-11-05 6:01 UTC (permalink / raw) To: Rusty Russell Cc: sfr, Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm, linuxppc-dev On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. What's the status with this patch ? The lack of it breaks my KVM stuff in powerpc... Cheers, Ben. > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -683,12 +683,6 @@ 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 > @@ -696,6 +690,33 @@ struct sysinfo { > #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 > +#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition) > + > /* Trap pasters of __FUNCTION__ at compile-time */ > #define __FUNCTION__ (__func__) > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 97+ messages in thread
* linux-next: tree build failure @ 2009-09-24 5:21 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-09-24 5:21 UTC (permalink / raw) To: ppc-dev Cc: linux-next, linux-kernel, Jan Beulich, Andrew Morton, Hollis Blanchard, kvm-ppc 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 '<anonymous>' 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 '<anonymous>' 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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 Rothwell sfr@canb.auug.org.au ^ permalink raw reply related [flat|nested] 97+ messages in thread
* linux-next: tree build failure @ 2009-09-24 5:21 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-09-24 5:21 UTC (permalink / raw) To: ppc-dev Cc: linux-next, linux-kernel, Jan Beulich, Andrew Morton, Hollis Blanchard, kvm-ppc 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 '<anonymous>' 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 '<anonymous>' 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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 Rothwell sfr@canb.auug.org.au ^ permalink raw reply related [flat|nested] 97+ messages in thread
* linux-next: tree build failure @ 2009-09-24 5:21 ` Stephen Rothwell 0 siblings, 0 replies; 97+ messages in thread From: Stephen Rothwell @ 2009-09-24 5:21 UTC (permalink / raw) To: ppc-dev Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich, Andrew Morton 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 '<anonymous>' 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 '<anonymous>' 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> --- 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 Rothwell sfr@canb.auug.org.au ^ permalink raw reply related [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 0:00 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw) To: Stephen Rothwell Cc: ppc-dev, linux-next, linux-kernel, Jan Beulich, Andrew Morton, kvm-ppc 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 '<anonymous>' 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 '<anonymous>' 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 0:00 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw) To: Stephen Rothwell Cc: ppc-dev, linux-next, linux-kernel, Jan Beulich, Andrew Morton, kvm-ppc 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 '<anonymous>' 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 '<anonymous>' 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 0:00 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw) To: Stephen Rothwell Cc: linux-kernel, kvm-ppc, linux-next, Jan Beulich, Andrew Morton, ppc-dev 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 '<anonymous>' 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 '<anonymous>' 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 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: linux-next: tree build failure @ 2009-09-29 0:00 ` Hollis Blanchard 0 siblings, 0 replies; 97+ messages in thread From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw) To: Stephen Rothwell Cc: ppc-dev, linux-next-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jan Beulich, Andrew Morton, kvm-ppc-u79uwXL29TY76Z2rM5mHXA 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 '<anonymous>' 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 '<anonymous>' 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2009-11-06 6:42 UTC | newest] Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-29 9:28 linux-next: tree build failure Jan Beulich 2009-09-29 9:28 ` Jan Beulich 2009-09-29 9:28 ` Jan Beulich 2009-09-29 9:28 ` Jan Beulich 2009-09-29 9:51 ` roel kluin 2009-09-29 9:51 ` roel kluin 2009-09-29 9:51 ` roel kluin 2009-09-29 9:51 ` roel kluin 2009-09-30 6:29 ` Jan Beulich 2009-09-30 6:29 ` Jan Beulich 2009-09-30 6:29 ` Jan Beulich 2009-09-30 6:29 ` Jan Beulich 2009-09-29 23:39 ` Hollis Blanchard 2009-09-29 23:39 ` Hollis Blanchard 2009-09-29 23:39 ` Hollis Blanchard 2009-09-29 23:39 ` Hollis Blanchard 2009-09-30 6:35 ` Jan Beulich 2009-09-30 6:35 ` Jan Beulich 2009-09-30 6:35 ` Jan Beulich 2009-09-30 6:35 ` Jan Beulich 2009-10-02 15:48 ` Hollis Blanchard 2009-10-02 15:48 ` Hollis Blanchard 2009-10-02 15:48 ` Hollis Blanchard 2009-10-02 15:48 ` Hollis Blanchard 2009-10-05 6:58 ` Jan Beulich 2009-10-05 6:58 ` Jan Beulich 2009-10-05 6:58 ` Jan Beulich 2009-10-05 6:58 ` Jan Beulich 2009-10-09 19:14 ` Hollis Blanchard 2009-10-09 19:14 ` Hollis Blanchard 2009-10-09 19:14 ` Hollis Blanchard 2009-10-14 22:57 ` Hollis Blanchard 2009-10-14 22:57 ` Hollis Blanchard 2009-10-14 22:57 ` Hollis Blanchard 2009-10-15 7:27 ` Jan Beulich 2009-10-15 7:27 ` Jan Beulich 2009-10-15 7:27 ` Jan Beulich 2009-10-15 7:27 ` Jan Beulich 2009-10-19 18:19 ` Hollis Blanchard 2009-10-19 18:19 ` Hollis Blanchard 2009-10-19 18:19 ` Hollis Blanchard 2009-10-20 1:12 ` Rusty Russell 2009-10-20 1:24 ` Rusty Russell 2009-10-20 1:12 ` Rusty Russell 2009-10-20 1:29 ` Hollis Blanchard 2009-10-20 1:29 ` Hollis Blanchard 2009-10-20 1:29 ` Hollis Blanchard 2009-10-20 1:29 ` Hollis Blanchard 2009-10-20 3:45 ` [PATCH] BUILD_BUG_ON: make it handle more cases Rusty Russell 2009-10-20 3:57 ` Rusty Russell 2009-10-20 3:45 ` Rusty Russell 2009-10-20 3:45 ` Rusty Russell 2009-10-20 13:58 ` Américo Wang 2009-10-20 13:58 ` Américo Wang 2009-10-20 13:58 ` Américo Wang 2009-10-20 14:43 ` Alan Jenkins 2009-10-20 14:43 ` Alan Jenkins 2009-10-20 14:43 ` Alan Jenkins 2009-10-23 1:50 ` Américo Wang 2009-10-23 1:50 ` Américo Wang 2009-10-23 1:50 ` Américo Wang 2009-10-23 1:50 ` Américo Wang 2009-10-22 21:04 ` Hollis Blanchard 2009-10-22 21:04 ` Hollis Blanchard 2009-10-22 21:04 ` Hollis Blanchard 2009-10-22 21:04 ` Hollis Blanchard 2009-10-29 21:30 ` Hollis Blanchard 2009-10-29 21:30 ` Hollis Blanchard 2009-10-29 21:30 ` Hollis Blanchard 2009-11-05 0:20 ` Stephen Rothwell 2009-11-05 0:20 ` Stephen Rothwell 2009-11-05 0:20 ` Stephen Rothwell 2009-11-05 0:20 ` Stephen Rothwell 2009-11-05 6:28 ` Rusty Russell 2009-11-05 6:40 ` Rusty Russell 2009-11-05 6:28 ` Rusty Russell 2009-11-05 6:37 ` Rusty Russell 2009-11-05 6:49 ` Rusty Russell 2009-11-05 6:37 ` Rusty Russell 2009-11-05 6:37 ` Rusty Russell 2009-11-05 6:38 ` Stephen Rothwell 2009-11-05 6:38 ` Stephen Rothwell 2009-11-05 6:38 ` Stephen Rothwell 2009-11-06 6:30 ` Rusty Russell 2009-11-06 6:42 ` Rusty Russell 2009-11-06 6:30 ` Rusty Russell 2009-11-06 6:30 ` Rusty Russell 2009-11-05 6:01 ` Benjamin Herrenschmidt 2009-11-05 6:01 ` Benjamin Herrenschmidt 2009-11-05 6:01 ` Benjamin Herrenschmidt -- strict thread matches above, loose matches on Subject: below -- 2009-09-24 5:21 linux-next: tree build failure Stephen Rothwell 2009-09-24 5:21 ` Stephen Rothwell 2009-09-24 5:21 ` Stephen Rothwell 2009-09-29 0:00 ` Hollis Blanchard 2009-09-29 0:00 ` Hollis Blanchard 2009-09-29 0:00 ` Hollis Blanchard 2009-09-29 0:00 ` Hollis Blanchard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.