[Bug middle-end/63220] error: inlining failed in call to always_inline

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to davidxl from comment #2)
> (In reply to Richard Biener from comment #1)
> > First of all you should mark the functions 'inline' as well.
> 
> This does not help.
> 
>   Then the issue
> > is that 'eq' is called indirectly which isn't allowed for always_inline
> > functions:
> 
> 
> Is this documented somewhere? A function can be called indirectly and
> directly. What is the right way to force inlining the direct calls?
> 
> A warning is already emitted about always_inline might not be inlinable, why
> the error?

@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function
independent of any restrictions that otherwise apply to inlining.
Failure to inline such a function is diagnosed as an error.
Note that if such a function is called indirectly the compiler may
or may not inline it depending on optimization level and a failure
to inline an indirect call may or may not be diagnosed.

always_inline is _not_ an optimization hint!  always_inline was meant
to mark functions that won't work correctly if not inlined.

There is no way to "force" only inlining of direct calls.

> > 
> > t.C:81:66: error: inlining failed in call to always_inline 'static constexpr
> > bool std::__1::char_traits<char>::eq(std::__1::char_traits<char>::char_type,
> > std::__1::char_traits<char>::char_type)': indirect function call with a yet
> > undetermined callee
> >        __attribute__ (( __always_inline__)) static constexpr bool
> > eq(char_type __c1, char_type __c2)  {
> >                                                                   ^
> > t.C:75:37: error: called from here
> >              if (!__pred(*__m1, *__m2)) { } 
> >                                      ^
> > 
> > which means this is a missed-optimization only.  The error is your fault.
> > 
> > Note that getting the error is unreliable so -O0 simply doesn't discover the
> > failed inlining.
> 
> -O2 works fine -- I have not debugged the problem -- but it seems to be some
> newly cloned cgraph edge to be in inconsistent state.
> 
> David