RE: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints

From: David Laight <David.Laight@ACULAB.COM>
To: 'Jiri Slaby' <jirislaby@kernel.org>, 'Tejun Heo' <tj@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Martin Liska <mliska@suse.cz>, Josef Bacik <josef@toxicpanda.com>,
	Jens Axboe <axboe@kernel.dk>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: RE: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints
Date: Tue, 13 Dec 2022 11:50:04 +0000	[thread overview]
Message-ID: <542d413b9d044474a34b6e7a40d70541@AcuMS.aculab.com> (raw)
In-Reply-To: <9d2ead31-efab-cf49-08d4-1e613382d89f@kernel.org>

From: Jiri Slaby
> Sent: 13 December 2022 11:15
> 
> On 13. 12. 22, 9:30, David Laight wrote:
> > From: Tejun Heo <htejun@gmail.com> On Behalf Of 'Tejun Heo'
> >> Sent: 12 December 2022 21:47
> >> To: Jiri Slaby <jirislaby@kernel.org>
> >> Cc: David Laight <David.Laight@ACULAB.COM>; Christoph Hellwig <hch@infradead.org>; linux-
> >> kernel@vger.kernel.org; Martin Liska <mliska@suse.cz>; Josef Bacik <josef@toxicpanda.com>; Jens
> Axboe
> >> <axboe@kernel.dk>; cgroups@vger.kernel.org; linux-block@vger.kernel.org
> >> Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints
> >>
> >> On Mon, Dec 12, 2022 at 01:14:31PM +0100, Jiri Slaby wrote:
> >>>> If so, my suggestion is just sticking with the old behavior until we switch
> >>>> to --std=g2x and then make one time adjustment at that point.
> >>>
> >>> So is the enum split OK under these circumstances?
> >>
> >> Oh man, it's kinda crazy that the compiler is changing in a way that the
> >> same piece of code can't be compiled the same way across two adjoining
> >> versions of the same compiler. But, yeah, if that's what gcc is gonna do and
> >> splitting enums is the only way to be okay across the compiler versions,
> >> there isn't any other choice we can make.
> >
> > It is also a silent code-breaker.
> > Compile this for 32bit x86:
> >
> > enum { a = 1, b = ~0ull};
> 
> But having ull in an enum is undefined anyway. C99 allows only int
> constants. gnuC supports ulong expressions (IIRC).

gcc supports 'long long' as well - 64bit on 32bit systems.

In practical terms it really doesn't matter what C99 (or any other
version) says, the important thing is that the compiler accepted it.

> > extern int foo(int, ...);
> > int f(void)
> > {
> >      return foo(0, a, 2);
> > }
> >
> > gcc13 pushes an extra zero onto the stack between the 1 and 2.
> 
> So this is sort of "expected".

For some definitions of "expected" :-)

Note that it (probably) makes no actual difference to some architectures
(like 64bit x86) where all varargs parameters are passed as 64bit.
Extending a value to 64bits just makes the high bits well defined.
(The high bits of stacked 32bit args are undefined.)

	David

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