On Fri, Oct 4, 2019 at 2:02 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Oct 2, 2019 at 7:11 PM Masahiro Yamada > <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > > > Macrofying the 'inline' is a horrid mistake that makes incorrect code work. > > It would eternally prevent people from writing portable, correct code. > > Please do not encourage to hide problems. > > Honestly, if the alternative to hiding problems is "use a macro", then > I'd rather hide the problems and just make "inline" means "inline". > > If "inline" means "it's just a hint, use macros", then inline is useless. For clarification, I am not saying "use macros" at all. I just want to annotate __always_inline for the case "2. code that if not inlined is somehow not correct." > If "inline" means "using this means that there are known compiler > bugs, but we don't know where they trigger", then inline is _worse_ > than useless. > > I do not see the big advantage of letting the compiler say "yeah, I'm > not going to do that, Dave". > > And I see a *huge* disadvantage when people are ignoring compiler > bugs, and are saying "use a macro". Seriously. Again, not saying "use a macro". > > Right now we see the obvious compiler bugs that cause build breakages. > How many non-obvious compiler bugs do we have? And how sure are you > that our code is "correct" after fixing a couple of obvious cases? > > As to "portable", nobody cares. We're a kernel. We aren't portable, > and never were. > > If this is purely about the fact that x86 is different from other > architectures, then let's remove the "compiler can do stupid things" > option on x86 too. It was never clear that it was a huge advantage. > > Linus -- Best Regards Masahiro Yamada
