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

[Jiri Slaby]

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