This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __MATH_INLINE - __extern_inline or __extern_always_inline?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 12 Apr 2012 13:21:22 -0700 (PDT)
- Subject: Re: __MATH_INLINE - __extern_inline or __extern_always_inline?
- References: <4F8731F6.6030904@suse.com>
> commit cd205654 changed the definition of __MATH_INLINE from
> __extern_inline to __extern_always_inline - but only on x86-64.
As I mentioned earlier, the current definition of __extern_always_inline is
inappropriate for pretty much any use except for _FORTIFY_SOURCE wrappers.
Despite the name, it also includes __attribute__((artificial)), which
affects error messages and DWARF generation. I don't think we want that on
normal miscellaneous inlines.
Given the nonobviousness of this, I think it would be appropriate to change
the macros so that __extern_always_inline is just what it sounds like and
we have a different macro for the _FORTIFY_SOURCE cases where we also want
the artificial attribute.
Separately, it's not really clear to me that always_inline is appropriate
for __MATH_INLINE. That means you want to inline math functions when it's
optimal, but I don't see why it should mean that you want to override the
compiler's judgment of when inlining is desireable.
Thanks,
Roland