[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiKoRSXMkwcMN=70nG8aOAJxuF3PUqHSBRJ7dTfnZ1n=g@mail.gmail.com>
Date: Fri, 23 Jun 2023 15:15:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Tejun Heo <tj@...nel.org>
Cc: Dave Airlie <airlied@...il.com>, Arnd Bergmann <arnd@...db.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm32 build warnings in workqueue.c
On Fri, 23 Jun 2023 at 12:48, Tejun Heo <tj@...nel.org> wrote:
>
> The behavior change in gcc-13 is fine on its own but it's frustrating
> because there's no way to obtain previous behavior
No, the previous gcc behavior was just buggy and wrong.
I'm actually surprised at what gcc did. It means that each enum, has a
different type. That's just completely wrong, and means that there is
no such thing as a proper enum type.
And the types are entirely random. They are *not* the types of the
initializers. Try this:
enum {
A = (char) 1,
B = (unsigned long) 2,
C = (long long) 3,
D = (unsigned long) 0x123456789,
};
int tA(void) { return sizeof(A); }
int tB(void) { return sizeof(B); }
int tC(void) { return sizeof(C); }
int tD(void) { return sizeof(D); }
int T(void) { return sizeof(enum bad); }
int crazy(void) { return sizeof(typeof(A)); }
and look at the insanity when you compile it with "gcc -S".
So no. There is NO WAY we want to ever "obtain previous behavior".
That is just garbage. Any code that depends on that behavior is just
actively wrong.
I had to go look at what sparse does, because I didn't think I would
ever have made it match that crazy gcc behavior.
But it does - because a few years ago Luc added the logic to match
gcc, and it never triggered me.
Oh, how very horrible.
Linus
Powered by blists - more mailing lists