This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __MATH_INLINE - __extern_inline or __extern_always_inline?


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]