[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0feJOsKMNP0zCdPho5XdD+NXFceUTTe1X6dA9OdWQntQ@mail.gmail.com>
Date: Fri, 25 Feb 2022 09:33:49 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Segher Boessenkool <segher@...nel.crashing.org>,
Anders Roxell <anders.roxell@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Michael Ellerman <mpe@...erman.id.au>,
"# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH 2/3] powerpc: fix build errors
On Fri, Feb 25, 2022 at 1:32 AM Nicholas Piggin <npiggin@...il.com> wrote:
> Excerpts from Segher Boessenkool's message of February 25, 2022 3:12 am:
> >> +#ifdef CONFIG_CC_IS_GCC
> >> +#if (GCC_VERSION >= 100000)
> >> +#if (CONFIG_AS_VERSION == 23800)
> >> +asm(".machine any");
> >> +#endif
> >> +#endif
> >> +#endif
> >> +#endif /* __ASSEMBLY__ */
> >
> > Abusing toplevel asm like this is broken and you *will* end up with
> > unhappiness all around.
>
> It actually unbreaks things and reduces my unhappiness. It's only done
> for broken compiler versions and only where as does not have the
> workaround for the breakage.
It doesn't work with clang, which always passes explicit .machine
statements around each inline asm, and it's also fundamentally
incompatible with LTO builds. Generally speaking, you can't expect
a top-level asm statement to have any effect inside of another
function.
Arnd
Powered by blists - more mailing lists