Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Wed, 2 Nov 2022 06:43:42 -1000
From:   'Tejun Heo' <tj@kernel.org>
To:     David Laight <David.Laight@aculab.com>
Cc:     Jiri Slaby <jirislaby@kernel.org>,
        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
Message-ID: <Y2KePvYRRMOrqzOe@slm.duckdns.org>
References: <20221031114520.10518-1-jirislaby@kernel.org>
 <Y1++fLJXkeZgtXR2@infradead.org>
 <Y2AMcSPAJpj6obSA@slm.duckdns.org>
 <d833ad15-f458-d43d-cab7-de62ff54a939@kernel.org>
 <Y2FNa4bGhJoevRKT@slm.duckdns.org>
 <2b975ee3117e45aaa7882203cf9a4db8@AcuMS.aculab.com>
 <Y2Kaghnu/sPvl0+g@slm.duckdns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y2Kaghnu/sPvl0+g@slm.duckdns.org>
Precedence: bulk

On Wed, Nov 02, 2022 at 06:27:46AM -1000, 'Tejun Heo' wrote:
> On Wed, Nov 02, 2022 at 08:35:34AM +0000, David Laight wrote:
> > I think the enums have to be split.
> > There will be other side effects of promoting the constants to 64bit
> > that are much more difficult to detect than the warnings from printf.
> 
> idk, I think I can just add LLU to everything and it should be fine.
> 
> > I'm also not sure whether the type is even consistent for 32bit
> > and 64bit builds.
> > Casts are (sort of) horrid.
> 
> Yeah, I don't think casts are the solution either. Lemme add LLU to
> everything and see how it works.

So adding LLU to initializers don't make the specific enum's type follow
suit. I guess type determination is really based on the value range. Oh man,
what a mess.

If we end up having to split the enum defs, that's what we'll do but this
doesn't sense to me. It's one thing to make one time adjustment when we
adopt -std=g2x. That's fine, but it makes no sense for the compiler to
change type behavior underneath existing code bases in a way that prevents
the same code to mean the same thing in adjacent and recent compiler
versions. Even if gcc goes for that for whatever reason, there gotta be an
option to keep the original behavior, right?

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.

Thanks.

-- 
tejun