Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[James Bottomley]

[Parisc list cc added]
On Mon, 2012-07-23 at 12:16 +0100, Mel Gorman wrote:
> On Mon, Jul 23, 2012 at 12:30:58AM +0800, Fengguang Wu wrote:
> > Hi Mel,
> > 
> > To be frank, I don't quite understand this build failure..
> > 
> > tree:   next/akpm akpm
> > head:   37e2ad4953983527f7bdb6831bf478eedcc84082
> > commit: 799dc3a908b1df8b766c35aefc24c1b5356aa051 [129/309] netvm: allow skb allocation to use PFMEMALLOC reserves
> > config: parisc-defconfig (attached as .config)
> > 
> > All related error/warning messages:
> > 
> > net/core/sock.c:274:36: error: initializer element is not constant
> > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > net/core/sock.c:274:36: error: initializer element is not constant
> > 
> 
> It looks parisc specific so am adding some parisc because this builds but
> I am less sure if it is actually correct. If it's correct, it should be
> appear before the swap-over-nfs patches to avoid bisection problems.
> I've added some parisc folk for review.
> 
> ---8<---
> parisc: Redefine ATOMIC_INIT and ATOMIC64_INIT like other architectures
> 
> The following build error occured during a parisc build with
> swap-over-NFS patches applied.
> 
> net/core/sock.c:274:36: error: initializer element is not constant
> net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> net/core/sock.c:274:36: error: initializer element is not constant
> 
> It's not obvious but this is due to how ATOMIC_INIT is defined on
> parisc. It should affect any user of STATIC_KEY_INIT_FALSE on that
> platform.
> 
> This patch makes the definition of ATOMIC_INIT on parisc to look like
> other arches definition.
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
>  arch/parisc/include/asm/atomic.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
> index 6c6defc..af9cf30 100644
> --- a/arch/parisc/include/asm/atomic.h
> +++ b/arch/parisc/include/asm/atomic.h
> @@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
>  
>  #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
>  
> -#define ATOMIC_INIT(i)	((atomic_t) { (i) })
> +#define ATOMIC_INIT(i)	{ (i) }
>  
>  #define smp_mb__before_atomic_dec()	smp_mb()
>  #define smp_mb__after_atomic_dec()	smp_mb()
> @@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
>  
>  #ifdef CONFIG_64BIT
>  
> -#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
> +#define ATOMIC64_INIT(i) { (i) }
>  
>  static __inline__ s64
>  __atomic64_add_return(s64 i, atomic64_t *v)

OK, I don't understand this either ... why would not casting to the
appropriate type suddenly stop warning about the initialiser being non
constant.  It looks like some type of gcc bug to me.  Our toolchain
expert (Dave) hangs out on the parisc list ... he'll want to know your
gcc -v.

James

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Mel Gorman]

On Mon, Jul 23, 2012 at 12:20:20PM +0100, James Bottomley wrote:
> [Parisc list cc added]
> On Mon, 2012-07-23 at 12:16 +0100, Mel Gorman wrote:
> > On Mon, Jul 23, 2012 at 12:30:58AM +0800, Fengguang Wu wrote:
> > > Hi Mel,
> > > 
> > > To be frank, I don't quite understand this build failure..
> > > 
> > > tree:   next/akpm akpm
> > > head:   37e2ad4953983527f7bdb6831bf478eedcc84082
> > > commit: 799dc3a908b1df8b766c35aefc24c1b5356aa051 [129/309] netvm: allow skb allocation to use PFMEMALLOC reserves
> > > config: parisc-defconfig (attached as .config)
> > > 
> > > All related error/warning messages:
> > > 
> > > net/core/sock.c:274:36: error: initializer element is not constant
> > > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > > net/core/sock.c:274:36: error: initializer element is not constant
> > > 
> > 
> > It looks parisc specific so am adding some parisc because this builds but
> > I am less sure if it is actually correct. If it's correct, it should be
> > appear before the swap-over-nfs patches to avoid bisection problems.
> > I've added some parisc folk for review.
> > 
> > ---8<---
> > parisc: Redefine ATOMIC_INIT and ATOMIC64_INIT like other architectures
> > 
> > The following build error occured during a parisc build with
> > swap-over-NFS patches applied.
> > 
> > net/core/sock.c:274:36: error: initializer element is not constant
> > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > net/core/sock.c:274:36: error: initializer element is not constant
> > 
> > It's not obvious but this is due to how ATOMIC_INIT is defined on
> > parisc. It should affect any user of STATIC_KEY_INIT_FALSE on that
> > platform.
> > 
> > This patch makes the definition of ATOMIC_INIT on parisc to look like
> > other arches definition.
> > 
> > Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > ---
> >  arch/parisc/include/asm/atomic.h |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
> > index 6c6defc..af9cf30 100644
> > --- a/arch/parisc/include/asm/atomic.h
> > +++ b/arch/parisc/include/asm/atomic.h
> > @@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
> >  
> >  #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
> >  
> > -#define ATOMIC_INIT(i)	((atomic_t) { (i) })
> > +#define ATOMIC_INIT(i)	{ (i) }
> >  
> >  #define smp_mb__before_atomic_dec()	smp_mb()
> >  #define smp_mb__after_atomic_dec()	smp_mb()
> > @@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
> >  
> >  #ifdef CONFIG_64BIT
> >  
> > -#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
> > +#define ATOMIC64_INIT(i) { (i) }
> >  
> >  static __inline__ s64
> >  __atomic64_add_return(s64 i, atomic64_t *v)
> 
> OK, I don't understand this either ... why would not casting to the
> appropriate type suddenly stop warning about the initialiser being non
> constant.  It looks like some type of gcc bug to me. 

I agree. I could not see any functional difference as such either but also
could not figure out why gcc would get it right for some arches and not
for others.

> Our toolchain
> expert (Dave) hangs out on the parisc list ... he'll want to know your
> gcc -v.
> 

I'm using the cross-compiler from
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/. I do
not know what compiler Fengguang Wu was using. 

Using built-in specs.
COLLECT_GCC=/home/mel/git-public/cross-compilers/gcc-4.6.3-nolibc/hppa-linux/bin/hppa-linux-gcc
COLLECT_LTO_WRAPPER=/home/mel/git-public/cross-compilers/gcc-4.6.3-nolibc/hppa-linux/bin/../libexec/gcc/hppa-linux/4.6.3/lto-wrapper
Target: hppa-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=hppa-linux --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--enable-targets=all --prefix=/opt/cross/gcc-4.6.3-nolibc/hppa-linux/
--enable-languages=c --with-newlib --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=release
--with-mpfr=/home/tony/buildall/src/sys-x86_64
--with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
--disable-libquadmath
Thread model: single
gcc version 4.6.3 (GCC) 

-- 
Mel Gorman
SUSE Labs

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Fengguang Wu]

On Mon, Jul 23, 2012 at 12:42:58PM +0100, Mel Gorman wrote:
> On Mon, Jul 23, 2012 at 12:20:20PM +0100, James Bottomley wrote:
> > [Parisc list cc added]
> > On Mon, 2012-07-23 at 12:16 +0100, Mel Gorman wrote:
> > > On Mon, Jul 23, 2012 at 12:30:58AM +0800, Fengguang Wu wrote:
> > > > Hi Mel,
> > > > 
> > > > To be frank, I don't quite understand this build failure..
> > > > 
> > > > tree:   next/akpm akpm
> > > > head:   37e2ad4953983527f7bdb6831bf478eedcc84082
> > > > commit: 799dc3a908b1df8b766c35aefc24c1b5356aa051 [129/309] netvm: allow skb allocation to use PFMEMALLOC reserves
> > > > config: parisc-defconfig (attached as .config)
> > > > 
> > > > All related error/warning messages:
> > > > 
> > > > net/core/sock.c:274:36: error: initializer element is not constant
> > > > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > > > net/core/sock.c:274:36: error: initializer element is not constant
> > > > 
> > > 
> > > It looks parisc specific so am adding some parisc because this builds but
> > > I am less sure if it is actually correct. If it's correct, it should be
> > > appear before the swap-over-nfs patches to avoid bisection problems.
> > > I've added some parisc folk for review.
> > > 
> > > ---8<---
> > > parisc: Redefine ATOMIC_INIT and ATOMIC64_INIT like other architectures
> > > 
> > > The following build error occured during a parisc build with
> > > swap-over-NFS patches applied.
> > > 
> > > net/core/sock.c:274:36: error: initializer element is not constant
> > > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > > net/core/sock.c:274:36: error: initializer element is not constant
> > > 
> > > It's not obvious but this is due to how ATOMIC_INIT is defined on
> > > parisc. It should affect any user of STATIC_KEY_INIT_FALSE on that
> > > platform.
> > > 
> > > This patch makes the definition of ATOMIC_INIT on parisc to look like
> > > other arches definition.
> > > 
> > > Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > > ---
> > >  arch/parisc/include/asm/atomic.h |    4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
> > > index 6c6defc..af9cf30 100644
> > > --- a/arch/parisc/include/asm/atomic.h
> > > +++ b/arch/parisc/include/asm/atomic.h
> > > @@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
> > >  
> > >  #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
> > >  
> > > -#define ATOMIC_INIT(i)	((atomic_t) { (i) })
> > > +#define ATOMIC_INIT(i)	{ (i) }
> > >  
> > >  #define smp_mb__before_atomic_dec()	smp_mb()
> > >  #define smp_mb__after_atomic_dec()	smp_mb()
> > > @@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
> > >  
> > >  #ifdef CONFIG_64BIT
> > >  
> > > -#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
> > > +#define ATOMIC64_INIT(i) { (i) }
> > >  
> > >  static __inline__ s64
> > >  __atomic64_add_return(s64 i, atomic64_t *v)
> > 
> > OK, I don't understand this either ... why would not casting to the
> > appropriate type suddenly stop warning about the initialiser being non
> > constant.  It looks like some type of gcc bug to me. 
> 
> I agree. I could not see any functional difference as such either but also
> could not figure out why gcc would get it right for some arches and not
> for others.

Will gcc create a temporary (and hence non constant) value for the
conversion?

> > Our toolchain
> > expert (Dave) hangs out on the parisc list ... he'll want to know your
> > gcc -v.
> > 
> 
> I'm using the cross-compiler from
> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/. I do
> not know what compiler Fengguang Wu was using. 

Yeah that's handy binaries and I'm using them in the x86 compile
servers. However this particular parisc-defconfig is compile tested in
an ia64 machine which is built from debian's gcc-4.7 source:

Using built-in specs.
COLLECT_GCC=/opt/cross/bin/hppa-linux-gcc
COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/hppa-linux/4.7/lto-wrapper
Target: hppa-linux
Configured with: /home/wfg/buildall/gcc-4.7-4.7.1/src/configure --target=hppa-linux --enable-targets=all --prefix=/opt/cross --enable-lang
uages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --enable-checking=release                         Thread model: single
gcc version 4.7.1 (GCC) 

Thanks,
Fengguang

> Using built-in specs.
> COLLECT_GCC=/home/mel/git-public/cross-compilers/gcc-4.6.3-nolibc/hppa-linux/bin/hppa-linux-gcc
> COLLECT_LTO_WRAPPER=/home/mel/git-public/cross-compilers/gcc-4.6.3-nolibc/hppa-linux/bin/../libexec/gcc/hppa-linux/4.6.3/lto-wrapper
> Target: hppa-linux
> Configured with: /home/tony/buildall/src/gcc/configure
> --target=hppa-linux --host=x86_64-linux-gnu --build=x86_64-linux-gnu
> --enable-targets=all --prefix=/opt/cross/gcc-4.6.3-nolibc/hppa-linux/
> --enable-languages=c --with-newlib --without-headers
> --enable-sjlj-exceptions --with-system-libunwind --disable-nls
> --disable-threads --disable-shared --disable-libmudflap --disable-libssp
> --disable-libgomp --disable-decimal-float --enable-checking=release
> --with-mpfr=/home/tony/buildall/src/sys-x86_64
> --with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
> --disable-libquadmath
> Thread model: single
> gcc version 4.6.3 (GCC) 
> 
> -- 
> Mel Gorman
> SUSE Labs

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[John David Anglin]

On 23-Jul-12, at 8:29 AM, Fengguang Wu wrote:

> On Mon, Jul 23, 2012 at 12:42:58PM +0100, Mel Gorman wrote:
>> On Mon, Jul 23, 2012 at 12:20:20PM +0100, James Bottomley wrote:
>>> [Parisc list cc added]
>>> On Mon, 2012-07-23 at 12:16 +0100, Mel Gorman wrote:
>>>> On Mon, Jul 23, 2012 at 12:30:58AM +0800, Fengguang Wu wrote:
>>>>> Hi Mel,
>>>>>
>>>>> To be frank, I don't quite understand this build failure..
>>>>>
>>>>> tree:   next/akpm akpm
>>>>> head:   37e2ad4953983527f7bdb6831bf478eedcc84082
>>>>> commit: 799dc3a908b1df8b766c35aefc24c1b5356aa051 [129/309]  
>>>>> netvm: allow skb allocation to use PFMEMALLOC reserves
>>>>> config: parisc-defconfig (attached as .config)
>>>>>
>>>>> All related error/warning messages:
>>>>>
>>>>> net/core/sock.c:274:36: error: initializer element is not constant
>>>>> net/core/sock.c:274:36: error: (near initialization for  
>>>>> 'memalloc_socks')
>>>>> net/core/sock.c:274:36: error: initializer element is not constant
>>>>>
>>>>
>>>> It looks parisc specific so am adding some parisc because this  
>>>> builds but
>>>> I am less sure if it is actually correct. If it's correct, it  
>>>> should be
>>>> appear before the swap-over-nfs patches to avoid bisection  
>>>> problems.
>>>> I've added some parisc folk for review.
>>>>
>>>> ---8<---
>>>> parisc: Redefine ATOMIC_INIT and ATOMIC64_INIT like other  
>>>> architectures
>>>>
>>>> The following build error occured during a parisc build with
>>>> swap-over-NFS patches applied.
>>>>
>>>> net/core/sock.c:274:36: error: initializer element is not constant
>>>> net/core/sock.c:274:36: error: (near initialization for  
>>>> 'memalloc_socks')
>>>> net/core/sock.c:274:36: error: initializer element is not constant
>>>>
>>>> It's not obvious but this is due to how ATOMIC_INIT is defined on
>>>> parisc. It should affect any user of STATIC_KEY_INIT_FALSE on that
>>>> platform.
>>>>
>>>> This patch makes the definition of ATOMIC_INIT on parisc to look  
>>>> like
>>>> other arches definition.
>>>>
>>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>>>> Signed-off-by: Mel Gorman <mgorman@suse.de>
>>>> ---
>>>> arch/parisc/include/asm/atomic.h |    4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/ 
>>>> include/asm/atomic.h
>>>> index 6c6defc..af9cf30 100644
>>>> --- a/arch/parisc/include/asm/atomic.h
>>>> +++ b/arch/parisc/include/asm/atomic.h
>>>> @@ -141,7 +141,7 @@ static __inline__ int  
>>>> __atomic_add_unless(atomic_t *v, int a, int u)
>>>>
>>>> #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
>>>>
>>>> -#define ATOMIC_INIT(i)	((atomic_t) { (i) })
>>>> +#define ATOMIC_INIT(i)	{ (i) }
>>>>
>>>> #define smp_mb__before_atomic_dec()	smp_mb()
>>>> #define smp_mb__after_atomic_dec()	smp_mb()
>>>> @@ -150,7 +150,7 @@ static __inline__ int  
>>>> __atomic_add_unless(atomic_t *v, int a, int u)
>>>>
>>>> #ifdef CONFIG_64BIT
>>>>
>>>> -#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
>>>> +#define ATOMIC64_INIT(i) { (i) }
>>>>
>>>> static __inline__ s64
>>>> __atomic64_add_return(s64 i, atomic64_t *v)
>>>
>>> OK, I don't understand this either ... why would not casting to the
>>> appropriate type suddenly stop warning about the initialiser being  
>>> non
>>> constant.  It looks like some type of gcc bug to me.
>>

Possibly, the cast causes the const attribute to be dropped...

>> I agree. I could not see any functional difference as such either  
>> but also
>> could not figure out why gcc would get it right for some arches and  
>> not
>> for others.
>
> Will gcc create a temporary (and hence non constant) value for the
> conversion?

Parisc is a callee copies architecture.  Thus, a structure passed as an
argument may be copied to a temporary.  This has been a source of
numerous bugs as the majority of architectures do it the other way  
round.

It would be easier to see what's happening with preprocessed source.

>
>>> Our toolchain
>>> expert (Dave) hangs out on the parisc list ... he'll want to know  
>>> your
>>> gcc -v.
>>>
>>
>> I'm using the cross-compiler from
>> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/. I  
>> do
>> not know what compiler Fengguang Wu was using.
>
> Yeah that's handy binaries and I'm using them in the x86 compile
> servers. However this particular parisc-defconfig is compile tested in
> an ia64 machine which is built from debian's gcc-4.7 source:
>
> Using built-in specs.
> COLLECT_GCC=/opt/cross/bin/hppa-linux-gcc
> COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/hppa-linux/4.7/lto-wrapper
> Target: hppa-linux
> Configured with: /home/wfg/buildall/gcc-4.7-4.7.1/src/configure -- 
> target=hppa-linux --enable-targets=all --prefix=/opt/cross --enable- 
> lang
> uages=c --without-headers --enable-sjlj-exceptions --with-system- 
> libunwind --disable-nls --disable-threads --disable-shared --disable- 
> libmudflap --disable-libssp --disable-libgomp --disable-decimal- 
> float --disable-libquadmath --enable- 
> checking=release                         Thread model: single
> gcc version 4.7.1 (GCC)
>
> Thanks,
> Fengguang
>
>> Using built-in specs.
>> COLLECT_GCC=/home/mel/git-public/cross-compilers/gcc-4.6.3-nolibc/ 
>> hppa-linux/bin/hppa-linux-gcc
>> COLLECT_LTO_WRAPPER=/home/mel/git-public/cross-compilers/gcc-4.6.3- 
>> nolibc/hppa-linux/bin/../libexec/gcc/hppa-linux/4.6.3/lto-wrapper
>> Target: hppa-linux
>> Configured with: /home/tony/buildall/src/gcc/configure
>> --target=hppa-linux --host=x86_64-linux-gnu --build=x86_64-linux-gnu
>> --enable-targets=all --prefix=/opt/cross/gcc-4.6.3-nolibc/hppa-linux/
>> --enable-languages=c --with-newlib --without-headers
>> --enable-sjlj-exceptions --with-system-libunwind --disable-nls
>> --disable-threads --disable-shared --disable-libmudflap --disable- 
>> libssp
>> --disable-libgomp --disable-decimal-float --enable-checking=release
>> --with-mpfr=/home/tony/buildall/src/sys-x86_64
>> --with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
>> --disable-libquadmath
>> Thread model: single
>> gcc version 4.6.3 (GCC)
>>
>> -- 
>> Mel Gorman
>> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
John David Anglin	dave.anglin@bell.net

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Fengguang Wu]

> It would be easier to see what's happening with preprocessed source.

Here is the line in sock.i:

struct static_key memalloc_socks = ((struct static_key) { .enabled = ((atomic_t) { (0) }) });

Thanks,
Fengguang

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[John David Anglin]

On 24-Jul-12, at 3:48 AM, Fengguang Wu wrote:

> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =  
> ((atomic_t) { (0) }) });


The above line contains two compound literals.  It also uses a  
designated initializer
to initialize the field enabled.  A compound literal is not a constant  
expression.

The location of the above statement isn't fully clear, but if a  
compound literal occurs
outside the body of a function, the initializer list must consist of  
constant expressions.

Removing "(atomic_t)" from the define results in a constant expression.

Test case:

typedef struct { long enabled; } atomic_t;
struct static_key { atomic_t enabled; int x; };
struct static_key memalloc_socks = ((struct static_key) { .enabled =  
((atomic_t) { (0) }) });

Dave
--
John David Anglin	dave.anglin@bell.net

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[James Bottomley]

On Tue, 2012-07-24 at 17:08 -0400, John David Anglin wrote:
> Removing "(atomic_t)" from the define results in a constant expression.

OK, so this is what I'll queue for fixes:

From: Mel Gorman <mgorman@suse.de> Date: Mon, 23 Jul 2012 12:16:19
Subject: [PATCH] [PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the  casts

The following build error occured during a parisc build with
swap-over-NFS patches applied.

net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index 6c6defc..af9cf30 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
 
 #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
 
-#define ATOMIC_INIT(i)	((atomic_t) { (i) })
+#define ATOMIC_INIT(i)	{ (i) }
 
 #define smp_mb__before_atomic_dec()	smp_mb()
 #define smp_mb__after_atomic_dec()	smp_mb()
@@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
 
 #ifdef CONFIG_64BIT
 
-#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
+#define ATOMIC64_INIT(i) { (i) }
 
 static __inline__ s64
 __atomic64_add_return(s64 i, atomic64_t *v)

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Tony Luck]

On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>> Here is the line in sock.i:
>>
>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>> ((atomic_t) { (0) }) });
>
> The above line contains two compound literals.  It also uses a designated
> initializer to initialize the field enabled.  A compound literal is not a
> constant expression.

Seeing the same thing on ia64 building next-20120726.  Same fix works
for me ... so I'll steal this whole changelog and attributes.

-Tony

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Fengguang Wu]

On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >> Here is the line in sock.i:
> >>
> >> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> >> ((atomic_t) { (0) }) });
> >
> > The above line contains two compound literals.  It also uses a designated
> > initializer to initialize the field enabled.  A compound literal is not a
> > constant expression.
> 
> Seeing the same thing on ia64 building next-20120726.  Same fix works
> for me ... so I'll steal this whole changelog and attributes.

I got the same error for alpha, the same fix applies.
---
From: Mel Gorman <mgorman@suse.de>
Subject: [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

The following build error occurred during an alpha build:

net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org>
---
 arch/alpha/include/asm/atomic.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux.orig/arch/alpha/include/asm/atomic.h	2012-05-24 19:03:06.000000000 +0800
+++ linux/arch/alpha/include/asm/atomic.h	2012-08-02 23:01:02.243224220 +0800
@@ -14,8 +14,8 @@
  */
 
 
-#define ATOMIC_INIT(i)		( (atomic_t) { (i) } )
-#define ATOMIC64_INIT(i)	( (atomic64_t) { (i) } )
+#define ATOMIC_INIT(i)		( { (i) } )
+#define ATOMIC64_INIT(i)	( { (i) } )
 
 #define atomic_read(v)		(*(volatile int *)&(v)->counter)
 #define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Michael Cree]

On 03/08/12 03:02, Fengguang Wu wrote:
> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>>>> Here is the line in sock.i:
>>>>
>>>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>>>> ((atomic_t) { (0) }) });
>>>
>>> The above line contains two compound literals.  It also uses a designated
>>> initializer to initialize the field enabled.  A compound literal is not a
>>> constant expression.
>>
>> Seeing the same thing on ia64 building next-20120726.  Same fix works
>> for me ... so I'll steal this whole changelog and attributes.
> 
> I got the same error for alpha, the same fix applies.

Just trying this patch on Alpha against v3.6-rc1 and it leads to new
compilation errors, namely:

init/init_task.c:12: error: braced-group within expression allowed only
inside a function
init/init_task.c:13: error: braced-group within expression allowed only
inside a function
init/init_task.c:16: error: braced-group within expression allowed only
inside a function
init/init_task.c:16: error: braced-group within expression allowed only
inside a function
make[1]: *** [init/init_task.o] Error 1

> ---
> From: Mel Gorman <mgorman@suse.de>
> Subject: [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
> 
> The following build error occurred during an alpha build:
> 
> net/core/sock.c:274:36: error: initializer element is not constant
> 
> Dave Anglin says:
>> Here is the line in sock.i:
>>
>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>> ((atomic_t) { (0) }) });
> 
> The above line contains two compound literals.  It also uses a designated
> initializer to initialize the field enabled.  A compound literal is not a
> constant expression.
> 
> The location of the above statement isn't fully clear, but if a compound
> literal occurs outside the body of a function, the initializer list must
> consist of constant expressions.
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Cc: <stable@vger.kernel.org>
> ---
>  arch/alpha/include/asm/atomic.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux.orig/arch/alpha/include/asm/atomic.h	2012-05-24 19:03:06.000000000 +0800
> +++ linux/arch/alpha/include/asm/atomic.h	2012-08-02 23:01:02.243224220 +0800
> @@ -14,8 +14,8 @@
>   */
>  
>  
> -#define ATOMIC_INIT(i)		( (atomic_t) { (i) } )
> -#define ATOMIC64_INIT(i)	( (atomic64_t) { (i) } )
> +#define ATOMIC_INIT(i)		( { (i) } )
> +#define ATOMIC64_INIT(i)	( { (i) } )
>  
>  #define atomic_read(v)		(*(volatile int *)&(v)->counter)
>  #define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Cheers
Michael.

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Fengguang Wu]

On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
> On 03/08/12 03:02, Fengguang Wu wrote:
> > On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
> >> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >>>> Here is the line in sock.i:
> >>>>
> >>>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> >>>> ((atomic_t) { (0) }) });
> >>>
> >>> The above line contains two compound literals.  It also uses a designated
> >>> initializer to initialize the field enabled.  A compound literal is not a
> >>> constant expression.
> >>
> >> Seeing the same thing on ia64 building next-20120726.  Same fix works
> >> for me ... so I'll steal this whole changelog and attributes.
> > 
> > I got the same error for alpha, the same fix applies.
> 
> Just trying this patch on Alpha against v3.6-rc1 and it leads to new
> compilation errors, namely:
> 
> init/init_task.c:12: error: braced-group within expression allowed only
> inside a function
> init/init_task.c:13: error: braced-group within expression allowed only
> inside a function
> init/init_task.c:16: error: braced-group within expression allowed only
> inside a function
> init/init_task.c:16: error: braced-group within expression allowed only
> inside a function
> make[1]: *** [init/init_task.o] Error 1

Sorry! This will actually compile:

-#define ATOMIC_INIT(i)         ( { (i) } )
+#define ATOMIC_INIT(i)         { (i) }

Ditto for the 64bit version. I'll send the updated patch.

Thanks,
Fengguang

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Michael Cree]

On 12/08/12 14:10, Fengguang Wu wrote:
> On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
>> On 03/08/12 03:02, Fengguang Wu wrote:
>>> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>>>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>>>> Here is the line in sock.i:
>>>>>>
>>>>>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>>>>>> ((atomic_t) { (0) }) });
>>>>>
>>>>> The above line contains two compound literals.  It also uses a designated
>>>>> initializer to initialize the field enabled.  A compound literal is not a
>>>>> constant expression.
>>>>
>>>> Seeing the same thing on ia64 building next-20120726.  Same fix works
>>>> for me ... so I'll steal this whole changelog and attributes.
>>>
>>> I got the same error for alpha, the same fix applies.
>>
>> Just trying this patch on Alpha against v3.6-rc1 and it leads to new
>> compilation errors, namely:
>>
>> init/init_task.c:12: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:13: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:16: error: braced-group within expression allowed only
>> inside a function
>> init/init_task.c:16: error: braced-group within expression allowed only
>> inside a function
>> make[1]: *** [init/init_task.o] Error 1
> 
> Sorry! This will actually compile:
> 
> -#define ATOMIC_INIT(i)         ( { (i) } )
> +#define ATOMIC_INIT(i)         { (i) }

Thanks, it now compiles correctly.  I'm currently collecting Alpha
patches to send on to Linus so will include this one.

Cheers
Michael.

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On 11-Aug-12, at 10:42 PM, Michael Cree wrote:

> On 12/08/12 14:10, Fengguang Wu wrote:
>> On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
>>> On 03/08/12 03:02, Fengguang Wu wrote:
>>>> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>>>>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>>>>> Here is the line in sock.i:
>>>>>>>
>>>>>>> struct static_key memalloc_socks = ((struct static_key)  
>>>>>>> { .enabled =
>>>>>>> ((atomic_t) { (0) }) });
>>>>>>
>>>>>> The above line contains two compound literals.  It also uses a  
>>>>>> designated
>>>>>> initializer to initialize the field enabled.  A compound  
>>>>>> literal is not a
>>>>>> constant expression.
>>>>>
>>>>> Seeing the same thing on ia64 building next-20120726.  Same fix  
>>>>> works
>>>>> for me ... so I'll steal this whole changelog and attributes.
>>>>
>>>> I got the same error for alpha, the same fix applies.
>>>
>>> Just trying this patch on Alpha against v3.6-rc1 and it leads to new
>>> compilation errors, namely:
>>>
>>> init/init_task.c:12: error: braced-group within expression allowed  
>>> only
>>> inside a function
>>> init/init_task.c:13: error: braced-group within expression allowed  
>>> only
>>> inside a function
>>> init/init_task.c:16: error: braced-group within expression allowed  
>>> only
>>> inside a function
>>> init/init_task.c:16: error: braced-group within expression allowed  
>>> only
>>> inside a function
>>> make[1]: *** [init/init_task.o] Error 1
>>
>> Sorry! This will actually compile:
>>
>> -#define ATOMIC_INIT(i)         ( { (i) } )
>> +#define ATOMIC_INIT(i)         { (i) }
>
> Thanks, it now compiles correctly.  I'm currently collecting Alpha
> patches to send on to Linus so will include this one.


A similar change applied to 3.5.1 stable compiles successfully
on parisc.

Regards,
Dave
--
John David Anglin	dave.anglin@bell.net



[-- Attachment #2: atomic.h.d.txt --]
[-- Type: text/plain, Size: 787 bytes --]

diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index 6c6defc..af9cf30 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
 
 #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
 
-#define ATOMIC_INIT(i)	((atomic_t) { (i) })
+#define ATOMIC_INIT(i)	{ (i) }
 
 #define smp_mb__before_atomic_dec()	smp_mb()
 #define smp_mb__after_atomic_dec()	smp_mb()
@@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
 
 #ifdef CONFIG_64BIT
 
-#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
+#define ATOMIC64_INIT(i) { (i) }
 
 static __inline__ s64
 __atomic64_add_return(s64 i, atomic64_t *v)

[PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

[Fengguang Wu]

From: Mel Gorman <mgorman@suse.de>

The following build error occurred during an alpha build:

net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Cc: <stable@vger.kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 arch/alpha/include/asm/atomic.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux.orig/arch/alpha/include/asm/atomic.h	2012-08-12 10:12:36.667523339 +0800
+++ linux/arch/alpha/include/asm/atomic.h	2012-08-12 10:12:37.659523362 +0800
@@ -14,8 +14,8 @@
  */
 
 
-#define ATOMIC_INIT(i)		( (atomic_t) { (i) } )
-#define ATOMIC64_INIT(i)	( (atomic64_t) { (i) } )
+#define ATOMIC_INIT(i)		{ (i) }
+#define ATOMIC64_INIT(i)	{ (i) }
 
 #define atomic_read(v)		(*(volatile int *)&(v)->counter)
 #define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Re: [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

[Andrew Morton]

On Sun, 12 Aug 2012 10:14:05 +0800
Fengguang Wu <fengguang.wu@intel.com> wrote:

> From: Mel Gorman <mgorman@suse.de>
> 
> The following build error occurred during an alpha build:
> 
> net/core/sock.c:274:36: error: initializer element is not constant
> 
> Dave Anglin says:
> > Here is the line in sock.i:
> >
> > struct static_key memalloc_socks = ((struct static_key) { .enabled =
> > ((atomic_t) { (0) }) });
> 
> The above line contains two compound literals.  It also uses a designated
> initializer to initialize the field enabled.  A compound literal is not a
> constant expression.
> 
> The location of the above statement isn't fully clear, but if a compound
> literal occurs outside the body of a function, the initializer list must
> consist of constant expressions.
> 
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

I'll remvoe the Cc:stable from this one - the regression is post-3.5.

Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Mel Gorman]

On Tue, Jul 24, 2012 at 05:08:04PM -0400, John David Anglin wrote:
> On 24-Jul-12, at 3:48 AM, Fengguang Wu wrote:
> 
> >Here is the line in sock.i:
> >
> >struct static_key memalloc_socks = ((struct static_key) { .enabled
> >= ((atomic_t) { (0) }) });
> 
> 
> The above line contains two compound literals.  It also uses a
> designated initializer
> to initialize the field enabled.  A compound literal is not a
> constant expression.
> 
> The location of the above statement isn't fully clear, but if a
> compound literal occurs
> outside the body of a function, the initializer list must consist of
> constant expressions.
> 
> Removing "(atomic_t)" from the define results in a constant expression.
> 
> Test case:
> 
> typedef struct { long enabled; } atomic_t;
> struct static_key { atomic_t enabled; int x; };
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });
> 

Thanks John for that explanation, it clears it up. The source of the
above line was linux-next/master:net/core/sock.c due to some patches I
merged. The exact line looks like this

struct static_key memalloc_socks = STATIC_KEY_INIT_FALSE;

and that thing in turns looks like

#define STATIC_KEY_INIT_FALSE ((struct static_key) \
        { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })

This is a standard use of a static key (http://lwn.net/Articles/487426/)
and as I expect there will be more use of this feature in the future
it's good to get it fixed up first.

Thanks James for picking this up and putting a changelog on it.

-- 
Mel Gorman
SUSE Labs