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

[Jiri Slaby <jirislaby@kernel.org>]

On 02. 11. 22, 17:43, 'Tejun Heo' wrote:
> 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?

Unfortunately not, see:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405#c8
(linked also from the commit log). We'd use such an option if there were 
one.

> 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?

thanks,
-- 
js
suse labs