On Fri, Jun 18, 2021 at 3:43 PM Tom Rix <trix@xxxxxxxxxx> wrote:
> On 6/18/21 1:20 AM, Arnd Bergmann wrote:
> > On Thu, Jun 17, 2021 at 11:44 PM <trix@xxxxxxxxxx> wrote:
> >> From: Tom Rix <trix@xxxxxxxxxx>
> >>
> >> This spurious error is reported for powerpc64, CONFIG_BUG=n
> >>
> >> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> >> index f152b9bb916fc..b250e06d7de26 100644
> >> --- a/include/asm-generic/bug.h
> >> +++ b/include/asm-generic/bug.h
> >> @@ -177,7 +177,10 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
> >>
> >> #else /* !CONFIG_BUG */
> >> #ifndef HAVE_ARCH_BUG
> >> -#define BUG() do {} while (1)
> >> +#define BUG() do { \
> >> + do {} while (1); \
> >> + unreachable(); \
> >> + } while (0)
> >> #endif
> > Please let's not go back to this version, we had good reasons to use
> > the infinite loop,
> > mostly to avoid undefined behavior that would lead to the compiler producing
> > completely random output in code paths that lead to a BUG() statement. Those
> > do cause other kinds of warnings from objtool and from other compilers.
> >
> > The obvious workaround here would be to add a return statement locally, but
> > it may also help to figure out what exactly triggers the warning, as I don't see
> > it in my randconfig builds and it may be that there is a bug elsewhere.
> >
> > I've tried a simple reproducer on https://godbolt.org/z/341P949bG that did not
> > show this warning in any of the compilers I tried. Can you try to narrow down
> > the exact compiler versions and commmand line options that produce the
> > warning? https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/ has
> > most of the supported gcc versions in case you need those.
>
> Please follow the link in the cover letter to the original issue
> reported for fs/afs/dir + gcc ppc64 9.x / 10.3.1
>
> Adding the return was the first, rejected solution.
Ok, I was able to reproduce it now and have a better idea of what is going on.
I also misread your patch (sorry about that), and missed that you keep the
"do {} while (1)" loop ahead of the unreachable(), and that should address
all the concerns I had. I would still try to find the old email thread about
the change, just to make sure we don't already know about other problems
with your version.
Arnd
