* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
[not found] ` <20120723111619.GT9222@suse.de>
@ 2012-07-23 11:20 ` James Bottomley
2012-07-23 11:42 ` Mel Gorman
0 siblings, 1 reply; 16+ messages in thread
From: James Bottomley @ 2012-07-23 11:20 UTC (permalink / raw)
To: Mel Gorman
Cc: Fengguang Wu, kernel-janitors, Kyle McMartin, Andrew Morton, LKML,
Parisc List
[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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-23 11:20 ` [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant James Bottomley
@ 2012-07-23 11:42 ` Mel Gorman
2012-07-23 12:29 ` Fengguang Wu
0 siblings, 1 reply; 16+ messages in thread
From: Mel Gorman @ 2012-07-23 11:42 UTC (permalink / raw)
To: James Bottomley
Cc: Fengguang Wu, kernel-janitors, Kyle McMartin, Andrew Morton, LKML,
Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-23 11:42 ` Mel Gorman
@ 2012-07-23 12:29 ` Fengguang Wu
2012-07-23 15:13 ` John David Anglin
0 siblings, 1 reply; 16+ messages in thread
From: Fengguang Wu @ 2012-07-23 12:29 UTC (permalink / raw)
To: Mel Gorman
Cc: James Bottomley, kernel-janitors, Kyle McMartin, Andrew Morton,
LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-23 12:29 ` Fengguang Wu
@ 2012-07-23 15:13 ` John David Anglin
2012-07-24 7:48 ` Fengguang Wu
0 siblings, 1 reply; 16+ messages in thread
From: John David Anglin @ 2012-07-23 15:13 UTC (permalink / raw)
To: Fengguang Wu
Cc: Mel Gorman, James Bottomley, kernel-janitors, Kyle McMartin,
Andrew Morton, LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-23 15:13 ` John David Anglin
@ 2012-07-24 7:48 ` Fengguang Wu
2012-07-24 21:08 ` John David Anglin
0 siblings, 1 reply; 16+ messages in thread
From: Fengguang Wu @ 2012-07-24 7:48 UTC (permalink / raw)
To: John David Anglin
Cc: Mel Gorman, James Bottomley, kernel-janitors, Kyle McMartin,
Andrew Morton, LKML, Parisc List
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-24 7:48 ` Fengguang Wu
@ 2012-07-24 21:08 ` John David Anglin
2012-07-25 5:10 ` James Bottomley
2012-07-25 8:27 ` [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant Mel Gorman
0 siblings, 2 replies; 16+ messages in thread
From: John David Anglin @ 2012-07-24 21:08 UTC (permalink / raw)
To: Fengguang Wu
Cc: Mel Gorman, James Bottomley, kernel-janitors, Kyle McMartin,
Andrew Morton, LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-24 21:08 ` John David Anglin
@ 2012-07-25 5:10 ` James Bottomley
2012-07-26 17:06 ` Tony Luck
2012-07-25 8:27 ` [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant Mel Gorman
1 sibling, 1 reply; 16+ messages in thread
From: James Bottomley @ 2012-07-25 5:10 UTC (permalink / raw)
To: John David Anglin
Cc: Fengguang Wu, Mel Gorman, kernel-janitors, Kyle McMartin,
Andrew Morton, LKML, Parisc List
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)
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-24 21:08 ` John David Anglin
2012-07-25 5:10 ` James Bottomley
@ 2012-07-25 8:27 ` Mel Gorman
1 sibling, 0 replies; 16+ messages in thread
From: Mel Gorman @ 2012-07-25 8:27 UTC (permalink / raw)
To: John David Anglin
Cc: Fengguang Wu, James Bottomley, kernel-janitors, Kyle McMartin,
Andrew Morton, LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-25 5:10 ` James Bottomley
@ 2012-07-26 17:06 ` Tony Luck
2012-08-02 15:02 ` Fengguang Wu
0 siblings, 1 reply; 16+ messages in thread
From: Tony Luck @ 2012-07-26 17:06 UTC (permalink / raw)
To: James Bottomley
Cc: John David Anglin, Fengguang Wu, Mel Gorman, kernel-janitors,
Kyle McMartin, Andrew Morton, LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-07-26 17:06 ` Tony Luck
@ 2012-08-02 15:02 ` Fengguang Wu
2012-08-12 1:33 ` Michael Cree
0 siblings, 1 reply; 16+ messages in thread
From: Fengguang Wu @ 2012-08-02 15:02 UTC (permalink / raw)
To: linux-alpha
Cc: Richard Henderson, Ivan Kokshaysky, Matt Turner, Tony Luck,
James Bottomley, John David Anglin, Mel Gorman, kernel-janitors,
Kyle McMartin, Andrew Morton, LKML, Parisc List
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-08-02 15:02 ` Fengguang Wu
@ 2012-08-12 1:33 ` Michael Cree
2012-08-12 2:10 ` Fengguang Wu
2012-08-12 2:14 ` [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts Fengguang Wu
0 siblings, 2 replies; 16+ messages in thread
From: Michael Cree @ 2012-08-12 1:33 UTC (permalink / raw)
To: Fengguang Wu
Cc: linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Tony Luck, James Bottomley, John David Anglin, Mel Gorman,
kernel-janitors, Kyle McMartin, Andrew Morton, LKML, Parisc List
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-08-12 1:33 ` Michael Cree
@ 2012-08-12 2:10 ` Fengguang Wu
2012-08-12 2:42 ` Michael Cree
2012-08-12 2:14 ` [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts Fengguang Wu
1 sibling, 1 reply; 16+ messages in thread
From: Fengguang Wu @ 2012-08-12 2:10 UTC (permalink / raw)
To: Michael Cree
Cc: linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Tony Luck, James Bottomley, John David Anglin, Mel Gorman,
kernel-janitors, Kyle McMartin, Andrew Morton, LKML, Parisc List
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
2012-08-12 1:33 ` Michael Cree
2012-08-12 2:10 ` Fengguang Wu
@ 2012-08-12 2:14 ` Fengguang Wu
2012-08-15 22:03 ` Andrew Morton
1 sibling, 1 reply; 16+ messages in thread
From: Fengguang Wu @ 2012-08-12 2:14 UTC (permalink / raw)
To: Michael Cree
Cc: linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Tony Luck, James Bottomley, John David Anglin, Mel Gorman,
kernel-janitors, Kyle McMartin, Andrew Morton, LKML, Parisc List
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-08-12 2:10 ` Fengguang Wu
@ 2012-08-12 2:42 ` Michael Cree
2012-08-12 13:00 ` John David Anglin
0 siblings, 1 reply; 16+ messages in thread
From: Michael Cree @ 2012-08-12 2:42 UTC (permalink / raw)
To: Fengguang Wu
Cc: linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Tony Luck, James Bottomley, John David Anglin, Mel Gorman,
kernel-janitors, Kyle McMartin, Andrew Morton, LKML, Parisc List
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant
2012-08-12 2:42 ` Michael Cree
@ 2012-08-12 13:00 ` John David Anglin
0 siblings, 0 replies; 16+ messages in thread
From: John David Anglin @ 2012-08-12 13:00 UTC (permalink / raw)
To: Michael Cree
Cc: Fengguang Wu, linux-alpha, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Tony Luck, James Bottomley, Mel Gorman,
kernel-janitors, Kyle McMartin, Andrew Morton, LKML, Parisc List
[-- 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)
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
2012-08-12 2:14 ` [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts Fengguang Wu
@ 2012-08-15 22:03 ` Andrew Morton
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Morton @ 2012-08-15 22:03 UTC (permalink / raw)
To: Fengguang Wu
Cc: Michael Cree, linux-alpha, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Tony Luck, James Bottomley, John David Anglin,
Mel Gorman, kernel-janitors, Kyle McMartin, LKML, Parisc List,
David Miller
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-08-15 22:03 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20120722163058.GB13376@localhost>
[not found] ` <20120723111619.GT9222@suse.de>
2012-07-23 11:20 ` [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant James Bottomley
2012-07-23 11:42 ` Mel Gorman
2012-07-23 12:29 ` Fengguang Wu
2012-07-23 15:13 ` John David Anglin
2012-07-24 7:48 ` Fengguang Wu
2012-07-24 21:08 ` John David Anglin
2012-07-25 5:10 ` James Bottomley
2012-07-26 17:06 ` Tony Luck
2012-08-02 15:02 ` Fengguang Wu
2012-08-12 1:33 ` Michael Cree
2012-08-12 2:10 ` Fengguang Wu
2012-08-12 2:42 ` Michael Cree
2012-08-12 13:00 ` John David Anglin
2012-08-12 2:14 ` [PATCH] [ALPHA] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts Fengguang Wu
2012-08-15 22:03 ` Andrew Morton
2012-07-25 8:27 ` [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant Mel Gorman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).