diff for duplicates of <20191001215827.GP25745@shell.armlinux.org.uk> diff --git a/a/1.txt b/N1/1.txt index d13aae1..2aa327b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -82,55 +82,3 @@ On Tue, Oct 01, 2019 at 02:32:54PM -0700, Nick Desaulniers wrote: > > (I wrote the kernel patch for gnu_inline; it only comes into play when > `inline` appears on a function *also defined as `extern`*). - -From what I can tell reading the GCC manual, the patch adding -gnu_inline should have no effect. Maybe it was written before --std=gnu89 was in use by the kernel makefiles? - -> > I'd suggest gnu90 mode is pretty similar to gnu89 mode, and as we build -> > the kernel in gnu89 mode, that is the inlining definition that is -> > appropriate. -> > -> > When it comes to __always_inline, the GCC manual is the definitive -> > reference, since we use the GCC attribute for that: -> > -> > #define __always_inline inline __attribute__((__always_inline__)) -> > -> > and I've already quoted what the GCC manual says for always_inline. -> > -> > Arguing about what the C11 spec says about inlining when we aren't -> > using C11 dialect in the kernel, but are using GCC features, does -> > not move the discussion on. -> > -> > Thanks anyway, maybe it will become relevent in the future if we -> > decide to move to C11. -> -> It's not like the semantics of inline are better specified by an older -> standard, or changed (The only real semantic change involving `inline` -> between ISO C90 and ISO C99 has to do with whether `extern inline` -> emits the function with external linkage as you noted). But that's -> irrelevant to the discussion.). I quoted C11 because ctrl+f doesn't -> work for the C90 ISO spec pdf. C90 spec doesn't even have a section -> on Function Specifiers. From what I can tell, `inline` wasn't -> specified until ISO C99. -> -> GNU modes are often modifiers off of ISO C bases; gnu89 corresponds to -> ISO C90. They may permit the use of features from newer ISO C specs -> and GNU C extensions without warning under -Wpedantic. There aren't a -> whole lot of semantic differences, at least that I'm aware of. - -Right, so GCC had inlining support before ISO C added it (which I -distinctly remember, I've been involved in Linux since 1994.) - -Unless ISO C based their definition in some way off GCC's -implementation, I still don't see how quoting ISO C documents -helps this discussion when it's the GCC feature that we're using. - -And none of this is relevent anyway if we use the GCC -always_inline extension *which is obviously the right way to -resolve this instance*. - --- -RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ -FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up -According to speedtest.net: 11.9Mbps down 500kbps up diff --git a/a/content_digest b/N1/content_digest index 8158bff..aa7ca78 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -112,58 +112,6 @@ "> > `-fgnu89-inline'), and the third is used when compiling C++.\n" "> \n" "> (I wrote the kernel patch for gnu_inline; it only comes into play when\n" - "> `inline` appears on a function *also defined as `extern`*).\n" - "\n" - "From what I can tell reading the GCC manual, the patch adding\n" - "gnu_inline should have no effect. Maybe it was written before\n" - "-std=gnu89 was in use by the kernel makefiles?\n" - "\n" - "> > I'd suggest gnu90 mode is pretty similar to gnu89 mode, and as we build\n" - "> > the kernel in gnu89 mode, that is the inlining definition that is\n" - "> > appropriate.\n" - "> >\n" - "> > When it comes to __always_inline, the GCC manual is the definitive\n" - "> > reference, since we use the GCC attribute for that:\n" - "> >\n" - "> > #define __always_inline inline __attribute__((__always_inline__))\n" - "> >\n" - "> > and I've already quoted what the GCC manual says for always_inline.\n" - "> >\n" - "> > Arguing about what the C11 spec says about inlining when we aren't\n" - "> > using C11 dialect in the kernel, but are using GCC features, does\n" - "> > not move the discussion on.\n" - "> >\n" - "> > Thanks anyway, maybe it will become relevent in the future if we\n" - "> > decide to move to C11.\n" - "> \n" - "> It's not like the semantics of inline are better specified by an older\n" - "> standard, or changed (The only real semantic change involving `inline`\n" - "> between ISO C90 and ISO C99 has to do with whether `extern inline`\n" - "> emits the function with external linkage as you noted). But that's\n" - "> irrelevant to the discussion.). I quoted C11 because ctrl+f doesn't\n" - "> work for the C90 ISO spec pdf. C90 spec doesn't even have a section\n" - "> on Function Specifiers. From what I can tell, `inline` wasn't\n" - "> specified until ISO C99.\n" - "> \n" - "> GNU modes are often modifiers off of ISO C bases; gnu89 corresponds to\n" - "> ISO C90. They may permit the use of features from newer ISO C specs\n" - "> and GNU C extensions without warning under -Wpedantic. There aren't a\n" - "> whole lot of semantic differences, at least that I'm aware of.\n" - "\n" - "Right, so GCC had inlining support before ISO C added it (which I\n" - "distinctly remember, I've been involved in Linux since 1994.)\n" - "\n" - "Unless ISO C based their definition in some way off GCC's\n" - "implementation, I still don't see how quoting ISO C documents\n" - "helps this discussion when it's the GCC feature that we're using.\n" - "\n" - "And none of this is relevent anyway if we use the GCC\n" - "always_inline extension *which is obviously the right way to\n" - "resolve this instance*.\n" - "\n" - "-- \n" - "RMK's Patch system: https://www.armlinux.org.uk/developer/patches/\n" - "FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up\n" - According to speedtest.net: 11.9Mbps down 500kbps up + > `inline` appears on a function *also defined as `extern`*). -8f4d3246e9fcc8a3816884875d62247134de062b6772f1961edad40b5e0d67ee +b3a34e481d65e24e141cfd0e3c0a67b971548b917f7a321a3e6a8c4ae04226a1
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox