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;
MIME-Version: 1.0
References: <CAPM=9twNnV4zMCvrPkw3H-ajZOH-01JVh_kDrxdPYQErz8ZTdA@mail.gmail.com>
 <CAHk-=wi=eDN4Ub0qSN27ztBAvHSXCyiY2stu3_XbTpYpQX4x7w@mail.gmail.com>
 <CAHk-=wg9p+oJtzC0582vke8whcWPNSC9eq0Z6kdnSqWMEpah7g@mail.gmail.com> <37e7ef6d-3a92-42ab-a949-59c18bccc510@app.fastmail.com>
In-Reply-To: <37e7ef6d-3a92-42ab-a949-59c18bccc510@app.fastmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 23 Jun 2023 12:42:35 -0700
Message-ID: <CAHk-=wiiUo0KOMGbrz2uOq9HzRh9HYXZrOC_CzwQRQ5AE5V7cw@mail.gmail.com>
Subject: Re: arm32 build warnings in workqueue.c
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Dave Airlie <airlied@gmail.com>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 23 Jun 2023 at 12:22, Arnd Bergmann <arnd@arndb.de> wrote:
>
> The short explanation of the change is that with the previous
> gcc and clang behavior, the type of 'enum foo' would be determined
> separately from the type of each individual constant, while the
> new behavior in gcc-13 makes them all have the same type.

Oh, I actually thought that gcc already did the new behavior long ago.
It's the only sane one. Enums should all have the same type, that's
the whole point of it.

But it explains why the warning only showed up on 32-bit, where the
enum presumably ended up as 'long long', which is the same size as a
pointer on 64-bit (so no complaint), but not on 32-bit.

Anyway, our kernel code was disgusting, and apparently relied on that
horrendously wrong model of enum types.

              Linus