public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Jiri Slaby'" <jirislaby@kernel.org>,
	"Martin Liška" <mliska@suse.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: RE: [PATCH] block: fix Werror=format with GCC 13
Date: Wed, 26 Oct 2022 08:16:53 +0000	[thread overview]
Message-ID: <067786a28a034bbeb8518984ef32ee04@AcuMS.aculab.com> (raw)
In-Reply-To: <bc107c62-25ab-f959-c5bc-d5bacc511f20@kernel.org>

From: Jiri Slaby
> Sent: 26 October 2022 08:18
> 
> On 24. 10. 22, 21:01, Martin Liška wrote:
> > Starting with GCC 13, since
> > [g3b3083a598ca3f4b] c: C2x enums wider than int [PR36113]
> >
> > GCC promotes enum values with larger than integer types to a wider type.
> > In case of the anonymous enum type in blk-iocost.c it is:
> >
> > enum {
> > 	MILLION			= 1000000,
> > ...
> >
> > 	WEIGHT_ONE		= 1 << 16,
> > ...
> > 	VTIME_PER_SEC_SHIFT	= 37,
> > 	VTIME_PER_SEC		= 1LLU << VTIME_PER_SEC_SHIFT,
> > ...
> >
> > as seen VTIME_PER_SEC cannot fit into 32-bits (int type), thus one needs
> > to use 'long unsigned int' in the format string.
> >
> > It fixes then the following 2 warnings:
> >
> > block/blk-iocost.c: In function ‘ioc_weight_prfill’:
> > block/blk-iocost.c:3035:37: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument
> 4 has type ‘long unsigned int’ [-Werror=format=]
> >   3035 |                 seq_printf(sf, "%s %u\n", dname, iocg->cfg_weight / WEIGHT_ONE);
> >        |                                    ~^            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >        |                                     |                             |
> >        |                                     unsigned int                  long unsigned int
> >        |                                    %lu
> > block/blk-iocost.c: In function ‘ioc_weight_show’:
> > block/blk-iocost.c:3045:34: error: format ‘%u’ expects argument of type ‘unsigned int’, but argument
> 3 has type ‘long unsigned int’ [-Werror=format=]
> >   3045 |         seq_printf(sf, "default %u\n", iocc->dfl_weight / WEIGHT_ONE);
> >        |                                 ~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >        |                                  |                      |
> >        |                                  unsigned int           long unsigned int
> >        |                                 %lu
> 
> But introduces two with gcc-12 ;):
>  > block/blk-iocost.c: In function ‘ioc_weight_prfill’:
>  > block/blk-iocost.c:3037:38: error: format ‘%lu’ expects argument of
> type ‘long unsigned int’, but argument 4 has type ‘u32’ {aka ‘unsigned
> int’} [-Werror=format=]
>  >  3037 |                 seq_printf(sf, "%s %lu\n", dname,
> iocg->cfg_weight / WEIGHT_ONE);
>  >       |                                    ~~^
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  >       |                                      |
>       |
>  >       |                                      long unsigned int
>       u32 {aka unsigned int}
>  >       |                                    %u
> 
> 
> Note that:
> 1) the specs says enum behaves as int, or uint in some cases
> 2) iocc->dfl_weight is u32, i.e. uint
>     WEIGHT_ONE is 1 << 16, i.e. int
>     so the promotion should be to s32/int. Or not?
> 
> I think gcc-13 is wrong -- incosistent with gcc-12 at least.

The presence of VTIME_PER_SEC in the enum forces the enum
to 64bits (this must be a gcc extension).

The change in gcc 13 seems to be that the types of all the
enum values are now (probably correctly) that of the enum.

So WEIGHT_ONE changes from 'unsigned int' to 'unsigned long'.

See: https://godbolt.org/z/6K4PoK9sv

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2022-10-26  8:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 19:01 [PATCH] block: fix Werror=format with GCC 13 Martin Liška
2022-10-26  7:18 ` Jiri Slaby
2022-10-26  8:16   ` David Laight [this message]
2022-10-26 20:11 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=067786a28a034bbeb8518984ef32ee04@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=axboe@kernel.dk \
    --cc=jirislaby@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox