On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam <tmsri...@google.com> wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>> * ipa-inline.c (inline_always_inline_functions): Pretend
> >>> always_inline
> >>> functions are inlined during failures to flag an error.
> >>> * gcc.target/i386/inline_error.c: New test.
> >
> >> This patch is OK if it passes testing.
> >
> > Two tests gcc.c-torture/compile/pr43791.c and pr44043.c are failing
> > because of always_inline functions being present that cannot be
> > inlined and the compiler is now generating error messages. I will fix
> > them and resend the patch.
>
> Quick look - pr43791.c is not expected to work at -O0, so skip -O0
> for example by guarding the whole thing with #if __OPTIMIZED__ > 0.
> Similar for pr44043.c.
>
> That we didn't error at -O0 before is a bug. Eventually I was suggesting
> to error if we end up outputting the body of an always_inline function,
> that is, any uses remain (including indirect calls or address-takens which
> is where we do not error right now).
Well, for indirect calls/address-takens and gnu_inline style extern inline
always_inline, it should be fine if we just emit calls to the library
function, otherwise you'd break a lot of code, because glibc uses
always_inline heavily for -D_FORTIFY_SOURCE wrapper inlines, open argument
checking etc. But that body supposedly doesn't inherit the always_inline
attribute.
Jakub
