Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1427495 > unrolled thread

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Tomas Winkler <tomasw@gmail.com> - 2016-06-21 11:20 +0200
    Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Tomas Winkler <tomasw@gmail.com> - 2016-06-22 10:40 +0200
      Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Arnd Bergmann <arnd@arndb.de> - 2016-06-22 12:20 +0200
        RE: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug "Levy, Amir (Jer)" <amir.jer.levy@intel.com> - 2016-06-22 12:40 +0200
          Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Tomas Winkler <tomasw@gmail.com> - 2016-06-22 13:50 +0200
            Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Arnd Bergmann <arnd@arndb.de> - 2016-06-22 14:40 +0200
              Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Tomas Winkler <tomasw@gmail.com> - 2016-06-23 08:30 +0200
                Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug Arnd Bergmann <arnd@arndb.de> - 2016-06-23 11:30 +0200

#1427495 — Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>> > >
>> > > > This is another attempt to avoid a regression in wwn_to_u64() after
>> > > > that started using get_unaligned_be64(), which in turn ran into a
>> > > > bug on gcc-4.9 through 6.1.
>> > >
>> > > I'm still getting a couple screenfuls of things like
>> > >
>> > > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':
>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'
>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'
>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'
>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'
>> >
>> > I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,
>> > but didn't see this one. What target architecture and compiler version produced
>> > this? Does it go away if you add a (__u32) cast? I don't even know what the
>> > warning is trying to tell me.
>>
>> heh, I didn't actually read it.
>>
>> Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.
>
> Ah, old compiler. I've tried gcc-4.3 now on ARM, and I don't get this warning
> (just a lot "may be used uninitialized"), but unlike gcc-4.4, my version doesn't
> actually get into the code path I have changed because __builtin_bswap32 was only
> introduced with 4.4.
>
> I don't have gcc-4.4 and 4.5 here, but the warning does show up with 4.6, 4.7
> and 4.8:
>
> drivers/soc/sunxi/sunxi_sram.c: In function ‘sunxi_sram_show’:
> drivers/soc/sunxi/sunxi_sram.c:103:7: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
>
> 4.8 is probably still common enough that we should try to address this.
> This change addresses the problem for me with ARM gcc-4.8, but adding
> two more type casts. This also makes the 16/32/64 bit swaps all
> look the same. I would expect this to also have the same effect on 4.4.
>
> Please fold into the previous patch.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> index d737804af181..8f3a8f606fd9 100644
> --- a/include/uapi/linux/swab.h
> +++ b/include/uapi/linux/swab.h
> @@ -97,7 +97,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>   * @x: value to byteswap
>   */
>  #ifdef __HAVE_BUILTIN_BSWAP16__
> -#define __swab16(x) __builtin_bswap16((__u16)(x))
> +#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
>  #else
>  #define __swab16(x)                            \
>         (__builtin_constant_p((__u16)(x)) ?     \
> @@ -110,7 +110,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>   * @x: value to byteswap
>   */
>  #ifdef __HAVE_BUILTIN_BSWAP32__
> -#define __swab32(x) __builtin_bswap32((__u32)(x))
> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
>  #else
>  #define __swab32(x)                            \
>         (__builtin_constant_p((__u32)(x)) ?     \

>

I wonder if this doesn't break switch statement that requires a
constant expression, there few cases like this over the kernel.

switch(val) {
case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):

http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458


Thanks
Tomas

[toc] | [next] | [standalone]

#1428560

On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
>>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>> > >
>>> > > > This is another attempt to avoid a regression in wwn_to_u64() after
>>> > > > that started using get_unaligned_be64(), which in turn ran into a
>>> > > > bug on gcc-4.9 through 6.1.
>>> > >
>>> > > I'm still getting a couple screenfuls of things like
>>> > >
>>> > > net/tipc/name_distr.c: In function 'tipc_named_process_backlog':
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'unsigned int'
>>> > > net/tipc/name_distr.c:330: warning: format '%u' expects type 'unsigned int', but argument 7 has type 'unsigned int'
>>> >
>>> > I've built a few thousand kernels (arm32 with gcc-6.1) with the patch applied,
>>> > but didn't see this one. What target architecture and compiler version produced
>>> > this? Does it go away if you add a (__u32) cast? I don't even know what the
>>> > warning is trying to tell me.
>>>
>>> heh, I didn't actually read it.
>>>
>>> Hopefully we can write this off as a gcc-4.4.4 glitch. 4.8.4 is OK.
>>
>> Ah, old compiler. I've tried gcc-4.3 now on ARM, and I don't get this warning
>> (just a lot "may be used uninitialized"), but unlike gcc-4.4, my version doesn't
>> actually get into the code path I have changed because __builtin_bswap32 was only
>> introduced with 4.4.
>>
>> I don't have gcc-4.4 and 4.5 here, but the warning does show up with 4.6, 4.7
>> and 4.8:
>>
>> drivers/soc/sunxi/sunxi_sram.c: In function ‘sunxi_sram_show’:
>> drivers/soc/sunxi/sunxi_sram.c:103:7: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
>>
>> 4.8 is probably still common enough that we should try to address this.
>> This change addresses the problem for me with ARM gcc-4.8, but adding
>> two more type casts. This also makes the 16/32/64 bit swaps all
>> look the same. I would expect this to also have the same effect on 4.4.
>>
>> Please fold into the previous patch.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
>> index d737804af181..8f3a8f606fd9 100644
>> --- a/include/uapi/linux/swab.h
>> +++ b/include/uapi/linux/swab.h
>> @@ -97,7 +97,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>>   * @x: value to byteswap
>>   */
>>  #ifdef __HAVE_BUILTIN_BSWAP16__
>> -#define __swab16(x) __builtin_bswap16((__u16)(x))
>> +#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
>>  #else
>>  #define __swab16(x)                            \
>>         (__builtin_constant_p((__u16)(x)) ?     \
>> @@ -110,7 +110,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>>   * @x: value to byteswap
>>   */
>>  #ifdef __HAVE_BUILTIN_BSWAP32__
>> -#define __swab32(x) __builtin_bswap32((__u32)(x))
>> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
>>  #else
>>  #define __swab32(x)                            \
>>         (__builtin_constant_p((__u32)(x)) ?     \
>
>>
>
> I wonder if this doesn't break switch statement that requires a
> constant expression, there few cases like this over the kernel.
>
> switch(val) {
> case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
>
> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458
>

I'm asking because sparse and checkpatch doesn't agree on that ping
sparse issues
'error: bad constant expression'
When changing to __constant_cpu_to_le32 sparse is happy but
checkpatch.ps is complaining
__constant_cpu_to_le32 should be cpu_to_le32



 Thanks
 Tomas

[toc] | [prev] | [next] | [standalone]

#1428652

On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:

> >>  #ifdef __HAVE_BUILTIN_BSWAP32__
> >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
> >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
> >>  #else
> >>  #define __swab32(x)                            \
> >>         (__builtin_constant_p((__u32)(x)) ?     \
> >
> >>
> >
> > I wonder if this doesn't break switch statement that requires a
> > constant expression, there few cases like this over the kernel.
> >
> > switch(val) {
> > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
> >
> > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c#L458
> >
> 
> I'm asking because sparse and checkpatch doesn't agree on that ping
> sparse issues
> 'error: bad constant expression'
> When changing to __constant_cpu_to_le32 sparse is happy but
> checkpatch.ps is complaining
> __constant_cpu_to_le32 should be cpu_to_le32
> 

That is an interesting problem, as both seem to be reasonable:
sparse probably doesn't understand __builtin_constant_p() enough,
while avoiding __constant_cpu_to_le32() is a good recommendation
in general.

How many instances of this do you see in the kernel? If ixgbe is the
only one, I'd just move the byteswap up into the switch statement:

	switch (le32_to_cpu(val)) {
	case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:

which may cost one or two cycles for the non-constant byteswap,
but is also easier to read than the current code.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1428667

On 2016-06-22 Arnd Bergmann wrote:
> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler <tomasw@gmail.com>
> wrote:
> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de>
> wrote:
> > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
> 
> > >>  #ifdef __HAVE_BUILTIN_BSWAP32__
> > >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
> > >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
> > >>  #else
> > >>  #define __swab32(x)                            \
> > >>         (__builtin_constant_p((__u32)(x)) ?     \
> > >
> > >>
> > >
> > > I wonder if this doesn't break switch statement that requires a
> > > constant expression, there few cases like this over the kernel.
> > >
> > > switch(val) {
> > > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
> > >
> > > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgb
> > > e/ixgbe_fcoe.c#L458
> > >
> >
> > I'm asking because sparse and checkpatch doesn't agree on that ping
> > sparse issues
> > 'error: bad constant expression'
> > When changing to __constant_cpu_to_le32 sparse is happy but
> > checkpatch.ps is complaining
> > __constant_cpu_to_le32 should be cpu_to_le32
> >
> 
> That is an interesting problem, as both seem to be reasonable:
> sparse probably doesn't understand __builtin_constant_p() enough, while
> avoiding __constant_cpu_to_le32() is a good recommendation in general.
> 
> How many instances of this do you see in the kernel? If ixgbe is the only one,
> I'd just move the byteswap up into the switch statement:
> 
> 	switch (le32_to_cpu(val)) {
> 	case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:
> 
> which may cost one or two cycles for the non-constant byteswap, but is also
> easier to read than the current code.
> 
> 	Arnd

There are more than 20 files that have the statement: case cpu_to_...
Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.

	Amir

[toc] | [prev] | [next] | [standalone]

#1428712

On Wed, Jun 22, 2016 at 1:25 PM, Levy, Amir (Jer)
<amir.jer.levy@intel.com> wrote:
> On 2016-06-22 Arnd Bergmann wrote:
>> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
>> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler <tomasw@gmail.com>
>> wrote:
>> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@arndb.de>
>> wrote:
>> > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>>
>> > >>  #ifdef __HAVE_BUILTIN_BSWAP32__
>> > >> -#define __swab32(x) __builtin_bswap32((__u32)(x))
>> > >> +#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
>> > >>  #else
>> > >>  #define __swab32(x)                            \
>> > >>         (__builtin_constant_p((__u32)(x)) ?     \
>> > >
>> > >>
>> > >
>> > > I wonder if this doesn't break switch statement that requires a
>> > > constant expression, there few cases like this over the kernel.
>> > >
>> > > switch(val) {
>> > > case cpu_to_le32(IXGBE_RXDADV_STAT_FCSTAT_FCPRSP):
>> > >
>> > > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/ixgb
>> > > e/ixgbe_fcoe.c#L458
>> > >
>> >
>> > I'm asking because sparse and checkpatch doesn't agree on that ping
>> > sparse issues
>> > 'error: bad constant expression'
>> > When changing to __constant_cpu_to_le32 sparse is happy but
>> > checkpatch.ps is complaining
>> > __constant_cpu_to_le32 should be cpu_to_le32
>> >
>>
>> That is an interesting problem, as both seem to be reasonable:
>> sparse probably doesn't understand __builtin_constant_p() enough, while
>> avoiding __constant_cpu_to_le32() is a good recommendation in general.
>>
>> How many instances of this do you see in the kernel? If ixgbe is the only one,
>> I'd just move the byteswap up into the switch statement:
>>
>>       switch (le32_to_cpu(val)) {
>>       case IXGBE_RXDADV_STAT_FCSTAT_FCPRSP:
>>
>> which may cost one or two cycles for the non-constant byteswap, but is also
>> easier to read than the current code.
>>
>>       Arnd
>
> There are more than 20 files that have the statement: case cpu_to_...
> Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.

There is even much more in the header files used in  initializers,
which also require constants.  I wonder if __builtin_bswap produces
constant expression correctly under gcc?

Thanks
Tomas

[toc] | [prev] | [next] | [standalone]

#1428751

On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
> >
> > There are more than 20 files that have the statement: case cpu_to_...
> > Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.
> 
> There is even much more in the header files used in  initializers,
> which also require constants.  I wonder if __builtin_bswap produces
> constant expression correctly under gcc?

In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we
have worked around now, as the 16-bit byteswap there was not a constant
expression, unlike the 32-bit and 64-bit ones.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1429503

On Wed, Jun 22, 2016 at 3:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
>> >
>> > There are more than 20 files that have the statement: case cpu_to_...
>> > Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.
>>
>> There is even much more in the header files used in  initializers,
>> which also require constants.  I wonder if __builtin_bswap produces
>> constant expression correctly under gcc?
>
> In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we
> have worked around now, as the 16-bit byteswap there was not a constant
> expression, unlike the 32-bit and 64-bit ones.

Can you please give any references to that?
Just to make sure we are on the same line , the  bottom line is that
sparse has to be adjusted.

Thanks
Tomas

[toc] | [prev] | [next] | [standalone]

#1429632

On Thursday, June 23, 2016 9:27:30 AM CEST Tomas Winkler wrote:
> On Wed, Jun 22, 2016 at 3:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
> >> >
> >> > There are more than 20 files that have the statement: case cpu_to_...
> >> > Sparse complains about: case __builtin_bswap, not about __builtin_constant_p.
> >>
> >> There is even much more in the header files used in  initializers,
> >> which also require constants.  I wonder if __builtin_bswap produces
> >> constant expression correctly under gcc?
> >
> > In gcc-4.8 or later yes. gcc-4.6/4.7 on powerpc was a special case that we
> > have worked around now, as the 16-bit byteswap there was not a constant
> > expression, unlike the 32-bit and 64-bit ones.
> 
> Can you please give any references to that?

The patch description for the last change has a good explanation:

commit 8634de6d254462e6953b7dac772a1df4f44c8030
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri May 6 09:22:25 2016 -0500

    compiler-gcc: require gcc 4.8 for powerpc __builtin_bswap16()
    
    gcc support for __builtin_bswap16() was supposedly added for powerpc in
    gcc 4.6, and was then later added for other architectures in gcc 4.8.
    
    However, Stephen Rothwell reported that attempting to use it on powerpc
    in gcc 4.6 fails with:
    
      lib/vsprintf.c:160:2: error: initializer element is not constant
      lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
      lib/vsprintf.c:160:2: error: initializer element is not constant
      lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
      ...
    
    I'm not entirely sure what those errors mean, but I don't see them on
    gcc 4.8.  So let's consider gcc 4.8 to be the official starting point
    for __builtin_bswap16().
    
    Arnd Bergmann adds:
     "I found the commit in gcc-4.8 that replaced the powerpc-specific
      implementation of __builtin_bswap16 with an architecture-independent
      one.  Apparently the powerpc version (gcc-4.6 and 4.7) just mapped to
      the lhbrx/sthbrx instructions, so it ended up not being a constant,
      though the intent of the patch was mainly to add support for the
      builtin to x86:
    
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624
    
      has the patch that went into gcc-4.8 and more information."
    
    Fixes: 7322dd755e7d ("byteswap: try to avoid __builtin_constant_p gcc bug")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

 include/linux/compiler-gcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


> Just to make sure we are on the same line , the  bottom line is that
> sparse has to be adjusted.

Yes, that sounds right. I don't know if sparse actually tracks the
value of the constant, or if it's good enough for sparse to know that
a constant input to __builtin_bswap results in a constant output.
If that is the case, we could just #define __builtin_bswap32(x) (x)
in the kernel headers when building with sparse, and have it work
for older sparse versions too.

	Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web