[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2bocgetbPQzy5xWhnW=mOdGynp_pWrPt6KeVTkEfEwKg@mail.gmail.com>
Date: Sun, 27 Feb 2022 22:28:41 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jakob <jakobkoschel@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Mike Rapoport <rppt@...nel.org>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
Brian Johannesmeyer <bjohannesmeyer@...il.com>,
Cristiano Giuffrida <c.giuffrida@...nl>,
"Bos, H.J." <h.j.bos@...nl>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
after the loop
On Sun, Feb 27, 2022 at 2:09 AM Segher Boessenkool
<segher@...nel.crashing.org> wrote:
>
> So imo we should just never do this by default, not just if the nasty
> -fwrapv or nastier -fno-strict-overflow is used, just like we suggest
> in our own documentation. The only valid reason -Wshift-negative-value
> is in -Wextra is it warns for situations that always are undefined
> behaviour (even if not in GCC).
Ok, I just realized that this is specific to the i915 driver because
that, unlike
most of the kernel builds with -Wextra by default. -Wextra is enabled when
users ask for a 'make W=1' build in linux, and i915 is one of just three
drivers that enable an equivalent set of warnings, the other ones
being greybus and btrfs.
This means to work around the extra warnings, we also just need to disable
it in the W=1 part of scripts/Makefile.extrawarn, as well as the three drivers
that copy those options, but not the default warnings that don't include them.
> Could you open a GCC PR for this? The current situation is quite
> suboptimal, and what we document as our implementation choice is much
> more useful!
I hope I managed to capture the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
Arnd
Powered by blists - more mailing lists