> 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, as dicussed earlier, this will make kernel folks crazy, since they define inline to be always inline and likes to take address of that function. (of course that is crazy already) Honza > > Richard. > > > Thanks > > Sri > > > >> Thanks for your patience! > > > > > > > >> > >> Honza
