https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 20 Feb 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 > > --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > As discussed elsewhere, always_inline is used in various ways, in some users I > guess would like to see an error if it wasn't inlined, but e.g. the uses in > glibc for _FORTIFY_SOURCE where many of the standard C or POSIX APIs have > extern inline wrappers with always_inline and gnu_inline attributes. In that > case always_inline is used there for security reasons (not inlining it means > the security checks aren't done) but on the other side C/POSIX requires &open > or &printf to work too. With GNU extern inline always_inline it would work to never emit bodies of always_inline functions to get the errors diagnosed at link time. Possibly standard C inline plus always_inline would work the same if we then treat the out of line instantiation as the destination for indirect calls. But I think the cgraph code is still not 100% accurate in reflecting reality with extern inlines (and possibly C 'inline' and instantiations), since it doesn't treat the inline copy and the out of line copy separately.
