This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: c tree inlining vs dwarf2


On Oct  8, 2001, Richard Henderson <rth@redhat.com> wrote:

> Dwarf2 expects any function that has been inlined to have the DECL_INLINE
> bit set.  Failure to do so will get it confused and abort trying to create
> a second die for the function.

Oops.  Would you believe I recalled dwarf2 depended on DECL_INLINE,
but disregarded the problem when the x86 -O3 bootstrap didn't fail :-(

> The C++ front end distinguishes between whether a function is declared
> inline, and whether it is inlinable.  At -O3, it sets DECL_INLINE on
> pretty much all functions.

> This changes the C front end to do the same thing.

Thanks!

May I suggest the following patch as a complement to yours?  Ok to
install?

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* tree-inline.c (inlinable_function_p): Leave it up to the
	front-end to turn -finline-functions into DECL_INLINE set for all
	functions.

Index: gcc/tree-inline.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/tree-inline.c,v
retrieving revision 1.5
diff -u -p -r1.5 tree-inline.c
--- gcc/tree-inline.c 2001/10/09 14:03:13 1.5
+++ gcc/tree-inline.c 2001/10/10 06:35:47
@@ -667,8 +667,12 @@ inlinable_function_p (fn, id)
   if (! flag_inline_trees)
     ;
   /* If we're not inlining all functions and the function was not
-     declared `inline', we don't inline it.  */
-  else if (flag_inline_trees < 2 && ! DECL_INLINE (fn))
+     declared `inline', we don't inline it.  Don't think of
+     disregarding DECL_INLINE when flag_inline_trees == 2; it's the
+     front-end that must set DECL_INLINE in this case, because
+     dwarf2out loses if a function is inlined that doesn't have
+     DECL_INLINE set.  */
+  else if (! DECL_INLINE (fn))
     ;
   /* We can't inline functions that are too big.  Only allow a single
      function to eat up half of our budget.  Make special allowance

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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