Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220217184829.1991035-1-jakobkoschel@gmail.com>
 <20220217184829.1991035-4-jakobkoschel@gmail.com> <CAHk-=wg1RdFQ6OGb_H4ZJoUwEr-gk11QXeQx63n91m0tvVUdZw@mail.gmail.com>
 <6DFD3D91-B82C-469C-8771-860C09BD8623@gmail.com> <CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com>
 <CAHk-=wgLe-OSLTEHm=V7eRG6Fcr0dpAM1ZRV1a=R_g6pBOr8Bg@mail.gmail.com> <20220226124249.GU614@gate.crashing.org>
In-Reply-To: <20220226124249.GU614@gate.crashing.org>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 26 Feb 2022 23:14:15 +0100
Message-ID: <CAK8P3a2Dd+ZMzn=gDnTzOW=S3RHQVmm1j3Gy=aKmFEbyD-q=rQ@mail.gmail.com>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
 after the loop
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Jakob <jakobkoschel@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>,
        Mike Rapoport <rppt@kernel.org>,
        "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
        Cristiano Giuffrida <c.giuffrida@vu.nl>,
        "Bos, H.J." <h.j.bos@vu.nl>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Feb 26, 2022 at 1:42 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Wed, Feb 23, 2022 at 11:23:39AM -0800, Linus Torvalds wrote:

> > That said, we seem to only have two cases of it in the kernel, at
> > least by a x86-64 allmodconfig build. So we could examine the types
> > there, or we could just add '-Wno-shift-negative-value".
>
> Yes.
>
> The only reason the warning exists is because it is undefined behaviour
> (not implementation-defined or anything).  The reason it is that in the
> standard is that it is hard to implement and even describe for machines
> that are not two's complement.  However relevant that is today :-)

Could gcc follow the clang behavior then and skip the warning and
sanitizer for this case when -fno-strict-overflow or -fwrapv are used?

         Arnd