On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>
>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
>> > > On Mon, 02 May 2016 23:48:19 +0200 Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxx>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
