[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgMR1-Syn8sPpZUXQVz_dnaeWB9SpmtUVKyLdfAqMryLQ@mail.gmail.com>
Date: Fri, 22 Jan 2021 09:47:35 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Will Deacon <will@...nel.org>
Cc: Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Catalin Marinas <catalin.marinas@....com>,
Jan Kara <jack@...e.cz>, Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Vinayak Menon <vinmenon@...eaurora.org>,
Hugh Dickins <hughd@...gle.com>,
kernel-team <kernel-team@...roid.com>
Subject: Re: [PATCH v4 8/8] mm: Mark anonymous struct field of 'struct
vm_fault' as 'const'
On Thu, Jan 21, 2021 at 5:11 AM Will Deacon <will@...nel.org> wrote:
>
> > (It turns out that sparse gets this wrong too, so it's not just clang).
>
> Adding Luc, as hopefully that's fixable.
I had talked to Luc about this earlier, and he just sent out a fix for
sparse. It's not in the git repo yet, but it's coming.
Having looked at what sparse does, I suspect the clang behavior stems
from a similar approach to looking up unnamed struct/union members.
And the sparse fix was fairly straightforward: changing the _lookup_
is painful, because that's late and trying to fix types after-the-fact
is just not great. But just (recursively) modifying the type modifiers
at type parsing time for anonymous struct/union members is quite
straightforward, probably in clang too.
So honestly - I think the clang push-back was by somebody who thought
it would be nasty to fix, and who was thus actively trying to mis-read
the standards language.
I'm not willing to argue with compiler people who do standards
language weasel-wording (I've seen it before, my life is too short to
deal with those kinds of people), but maybe Nick is more used to deal
with clang people.
Nick - I suspect that the sparse type system model is different enough
from the clang one that the sparse patch is not really helpful as a
"look, this is how it was done in sparse, maybe clang can do something
similar", but I'll bounce it to you separately anyway just in case.
Maybe your clang knowledge means that you go "yeah, in clang that
function is called 'xyz', and we can do something very similar".
Linus
Powered by blists - more mailing lists