[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0_6zigntTWQs2vhJNwagmYyVHPQE2HggVVTmn+2u8siw@mail.gmail.com>
Date: Mon, 2 Nov 2020 23:29:15 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Kalle Valo <kvalo@...eaurora.org>,
QCA ath9k Development <ath9k-devel@....qualcomm.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
linux-wireless <linux-wireless@...r.kernel.org>,
Networking <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning
On Mon, Nov 2, 2020 at 7:01 PM Johannes Berg <johannes@...solutions.net> wrote:
> On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> > Arnd Bergmann <arnd@...nel.org> writes:
> > > From: Arnd Bergmann <arnd@...db.de>
> >
> > Isn't there a better way to handle this? I really would not want
> > checking for GCC versions become a common approach in drivers.
> >
> > I even think that using memcpy() always is better than the ugly ifdef.
>
> If you put memcpy() always somebody will surely go and clean it up to
> use ether_addr_copy() soon ...
>
> That said, if there's a gcc issue with ether_addr_copy() then how come
> it's specific to this place?
I have not been able to figure this out, hopefully some gcc developer
eventually looks at the bug in more detail.
Presumably it has something to do with the specific way the five levels
of structures are nested here, and how things get inlined in this driver.
If the bug happened everywhere, it would likely have been found and
fixed earlier.
Arnd
Powered by blists - more mailing lists