[lkml]   [2018]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] x86, kbuild: revert macrofying inline assembly code
> On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <> 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:
> 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 <> # distcc
> Reported-by: Sedat Dilek <> # 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: . 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).

 \ /
  Last update: 2018-12-16 04:29    [W:0.083 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site