From: Jiri Slaby <email@example.com>
To: 'Tejun Heo' <firstname.lastname@example.org>, David Laight <David.Laight@aculab.com>
Cc: Christoph Hellwig <email@example.com>,
Martin Liska <firstname.lastname@example.org>, Josef Bacik <email@example.com>,
Jens Axboe <firstname.lastname@example.org>,
Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints
Date: Mon, 12 Dec 2022 13:14:31 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
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:
(linked also from the commit log). We'd use such an option if there were
> 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?
next prev parent reply other threads:[~2022-12-12 12:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 11:45 [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints Jiri Slaby (SUSE)
2022-10-31 12:24 ` Christoph Hellwig
2022-10-31 17:57 ` Tejun Heo
2022-11-01 5:46 ` Jiri Slaby
2022-11-01 16:46 ` Tejun Heo
2022-11-02 8:35 ` David Laight
2022-11-02 16:27 ` 'Tejun Heo'
2022-11-02 16:43 ` 'Tejun Heo'
2022-12-12 12:14 ` Jiri Slaby [this message]
2022-12-12 21:46 ` 'Tejun Heo'
2022-12-13 8:30 ` David Laight
2022-12-13 11:15 ` Jiri Slaby
2022-12-13 11:50 ` David Laight
2022-12-13 12:05 ` Jiri Slaby
2022-12-13 12:58 ` David Laight
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.