Messages in this thread | | | Subject | Re: [RFC PATCH 0/5] make use of gcc 9's "asm inline()" | From | Rasmus Villemoes <> | Date | Fri, 30 Aug 2019 09:45:07 +0200 |
| |
On 29/08/2019 18.05, Linus Torvalds wrote: > On Thu, Aug 29, 2019 at 1:32 AM Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: >> >> But since we #define the identifier inline to attach some attributes, >> we have to use the alternate spelling __inline__ of that >> keyword. Unfortunately, we also currently #define that one (to >> inline), so we first have to get rid of all (mis)uses of >> __inline__. Hence the huge diffstat. > > Ugh. Not pretty, but I guess we're stuck with it. > > However, it worries me a bit that you excluide the UAPI headers where > we still use "__inline__", and now the semantics of that will change > for the kernel (for some odd gcc versions).
Yeah, as I wrote I was aware of that, but didn't have any good ideas, so I was fishing. Doing
#ifdef __KERNEL__ #define __uapi_inline inline #else #define __uapi_inline __inline__ #endif
was one of the bad ideas...
> I suspect we should just bite the bullet and you should do it to the > uapi headers too. We already use "inline" in a lot of them, so it's > not the case that we're using __inline__ because of some namespace > issue, as far as I can tell. > > One option might be to just use "__inline" for the asm_inline thing. > We have way fewer of those. That would make the noise much less for > this patch series.
Ah, interesting. I didn't know that was also a compiler provided alias. It seems to be entirely undocumented - https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html just mentions the __inline__ (and __asm__) spellings. But it's clear as day in the gcc sources
{ "__inline", RID_INLINE, 0 }, { "__inline__", RID_INLINE, 0 },
and has been that way since forever, AFAICT.
So yes, let's just start by getting rid of the __inline define and fix the staging (+acpi,zstd) users, to allow asm_inline to progress. I'll respin.
Rasmus
| |