On Tue, May 5, 2020 at 5:36 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Tue, May 5, 2020 at 8:33 AM Arnd Bergmann wrote:
> >
> > I'm not sure if there is anything to be done about it in clang, since it
> > always does syntactic analysis before dead-code elimination by design.
>
> That
On Tue, May 5, 2020 at 8:33 AM Arnd Bergmann wrote:
>
> On Tue, May 5, 2020 at 4:08 PM Andy Shevchenko
> wrote:
> > On Tue, May 5, 2020 at 4:58 PM Arnd Bergmann wrote:
> > > Clang normally does not warn about certain issues in inline functions when
> > > it only happens in an eliminated code pat
On Tue, May 5, 2020 at 4:08 PM Andy Shevchenko
wrote:
> On Tue, May 5, 2020 at 4:58 PM Arnd Bergmann wrote:
> > Clang normally does not warn about certain issues in inline functions when
> > it only happens in an eliminated code path. However if something else
> > goes wrong, it does tend to comp
On Tue, May 5, 2020 at 4:58 PM Arnd Bergmann wrote:
>
> Clang normally does not warn about certain issues in inline functions when
> it only happens in an eliminated code path. However if something else
> goes wrong, it does tend to complain about the definition of hweight_long()
> on 32-bit targe
On Tue, May 05, 2020 at 03:54:57PM +0200, Arnd Bergmann wrote:
> Clang normally does not warn about certain issues in inline functions when
> it only happens in an eliminated code path. However if something else
> goes wrong, it does tend to complain about the definition of hweight_long()
> on 32-b
Clang normally does not warn about certain issues in inline functions when
it only happens in an eliminated code path. However if something else
goes wrong, it does tend to complain about the definition of hweight_long()
on 32-bit targets:
include/linux/bitops.h:75:41: error: shift count >= width
6 matches
Mail list logo
