> On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masah...@socionext.com>
> wrote:
>
> Revert the following 9 commits:
>
> [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
> work around GCC inlining bugs")
>
> This was partially reverted because it made good cleanups
> irrespective of the inlining issue; the error message is still
> unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should
> be kept.
>
> [2] d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to
> work around GCC inlining bugs")
>
> [3] 0474d5d9d2f7 ("x86/extable: Macrofy inline assembly code to work
> around GCC inlining bugs")
>
> [4] 494b5168f2de ("x86/paravirt: Work around GCC inlining bugs when
> compiling paravirt ops")
>
> [5] f81f8ad56fd1 ("x86/bug: Macrofy the BUG table section handling,
> to work around GCC inlining bugs")
>
> [6] 77f48ec28e4c ("x86/alternatives: Macrofy lock prefixes to work
> around GCC inlining bugs")
>
> [7] 9e1725b41059 ("x86/refcount: Work around GCC inlining bug")
>
> Resolved conflicts in arch/x86/include/asm/refcount.h caused by
> 288e4521f0f6 ("x86/asm: 'Simplify' GEN_*_RMWcc() macros").
>
> [8] c06c4d809051 ("x86/objtool: Use asm macros to work around GCC
> inlining bugs")
>
> [9] 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in inline
> assembly code to work around asm() related GCC inlining bugs")
>
> A few days after those commits applied, discussion started to solve
> the issue more elegantly with the help of compiler:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92&data=02%7C01%7Cnamit%40vmware.com%7Ce893ce88065e4c59236308d663019424%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636805255787607178&sdata=miiUndmPfGNKvrzD5mttC1%2Bn6rNaoIFebjZOAkBr24Y%3D&reserved=0
>
> The new syntax "asm inline" was implemented by Segher Boessenkool, and
> now queued up for GCC 9. (People were positive even for back-porting it
> to older compilers).
>
> Since the in-kernel workarounds merged, some issues have been reported:
> breakage of building with distcc/icecc, breakage of distro packages for
> module building. (More fundamentally, we cannot build external modules
> after 'make clean'.)
>
> I do not want to mess up the build system any more.
>
> Given that this issue will be solved in a cleaner way sooner or later,
> let's revert the in-kernel workarounds, and wait for GCC 9.
>
> Reported-by: Logan Gunthorpe <log...@deltatee.com> # distcc
> Reported-by: Sedat Dilek <sedat.di...@gmail.com> # deb/rpm package
It is customary to cc those who report an issue.
The distcc issue has already been resolved both in distcc and in the patches
I’ve sent: https://lkml.org/lkml/2018/11/15/467 . So I cannot understand why
it is mentioned as a motivation.
It sounds that the external modules can easily be resolved. Can you please
provide a link for the bug report?
Please regard my comments regarding v1. I must admit that I’m very surprised
that you don’t like the patches since you ack’d the original patch-set (and
actually assisted me in changing the Makefile).
