From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Anders Roxell <anders.roxell@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Yang Li <yang.lee@linux.alibaba.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: outside array bounds error on ppc64_defconfig, GCC 12.1.0
Date: Tue, 7 Jun 2022 10:15:41 -0500 [thread overview]
Message-ID: <20220607151541.GG25951@gate.crashing.org> (raw)
In-Reply-To: <d38aeb0d6f2040369256ee640b44fafe@AcuMS.aculab.com>
On Tue, Jun 07, 2022 at 02:23:25PM +0000, David Laight wrote:
> > I don't see a really simple fix. I tried clamping the size parameter to
> > do_byte_reverse() with max(), but that didn't work :/
>
> I had a quick look at the code - it is somewhat horrid!
> Not really surprising the compiler is confused.
> Although it shouldn't be outputting that error message
> unless it is certain.
No. It is a warning message, and the compiler should output it for all
code it finds suspicious. The conditions for this could be improved for
sure, but it is and will remain a heuristic affair, so using -Werror
with is is akin to self-flagellation.
It is not an error, it is a warning. The correct response to it when
you determine it is not an error, or even you do not want to deal with
it now, is to ignore it. Which -Werror prevents, one of the ways that
that warning flag is counterproductive to use.
> Could it be re-written to read the data into an __u128
> (or whatever the compiler type is).
> Optionally byteswap the entire thing (swap the words and
> then byteswap each word).
> The do a put_user_8/16/32/64() to write out the value.
>
> I think that would remove all the memory accesses and make
> it a lot faster as well.
Yes, the warning sometimes fires for correct code that is "merely" next
to impossible to read. It may well improve even the performance of the
code if the code is rewritten.
But it also may introduce new bugs, or anything else detrimental. It
is yakshaving extraordinaire to do this every time a compiler warning
points out something doesn't smell quite right :-)
Segher
next prev parent reply other threads:[~2022-06-07 15:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 2:52 outside array bounds error on ppc64_defconfig, GCC 12.1.0 Bagas Sanjaya
2022-06-07 2:05 ` Michael Ellerman
2022-06-07 14:23 ` David Laight
2022-06-07 15:15 ` Segher Boessenkool [this message]
2022-06-07 15:04 ` Segher Boessenkool
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220607151541.GG25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=David.Laight@ACULAB.COM \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=bagasdotme@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=yang.lee@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).