[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220227224352.GA614@gate.crashing.org>
Date: Sun, 27 Feb 2022 16:43:52 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: 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 10:28:41PM +0100, Arnd Bergmann wrote:
> 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.
Ah good, all of the workaround in one simple place, neat.
> > 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
That looks fine. Thank you!
(I attached the testcase to the bug itself, we prefer it that way, maybe
godbolt will go away some day, who knows.)
Segher
Powered by blists - more mailing lists