Fix C/C++ inlinability tests

Jan Hubicka
Tue Sep 9 20:47:00 GMT 2003

> Hi,
> > ! 		 &DECL_SOURCE_LOCATION (fn), fn);
> > !       return 1;
> > !     }
> So this will warn for every function? I think one warning is enough, I
> suppose someone who uses -fno-inline.
right... I will fix that.
> > ! 	{
> > ! 	  if (do_warning)
> > ! 	    warning ("%Hfunction '%F' can never be inlined because it has "
> > ! 		     "pending sizes",
> > ! 		     &DECL_SOURCE_LOCATION (fn), fn);
> Is Joe User going to have a clue what you mean with pending sizes?

Definitly not, but I didn't find much better way to explain something so
crazy.  Hope Joe User will interpret it as "well my compiler is crazy"
and figure out by experimentation what is going on.
> I had a patch at some point to move this check from the C/C++ front ends
> to tree-inline, but it wouldn't work with C++. The C++ front end also
> checks for setjmp, but way earlier for some reason (something with
> templates not yet being available when the check for setjmp happend,
> IIRC -- but it's been a while...). You're not seeing any trouble with
> your setjmp check here?

I didn't seen any trouble, but perhaps I missed it.  Do you remember
what was the symptom?
> > ! 	  inline_forbidden_reason = "%Hfunction '%F' can never be inlined "
> > ! 				    "because it contains nested function";
> > ! 	  return node;
> > ! 	}
> > !       break;
> For some time I've been wondering: is this still true if all nested
> function calls are themselves tree-inlined, and would there any way to
> make sure that this is the case?

I guess you will need to produce new nested functions for each time you
inline the outer function to get frame accesses right.
As Richard mentioned, we should unnest the nested functions that has no
reason to be nested.  We also can add the inlining machinery, but
honestly I think it is not worthwhile for such a crazy feature (of
course until we get some of frontends where nested functions are common)
> > ! 
> > ! 	   void F (int i) { struct S { int ar[i]; } s; }
> > ! 
> > ! 	 Attempting to do so produces a catch-22 in tree-inline.c.
> Hmm the patch is big enough that I'm not sure, but isn't _this_ code in
> tree-inline.c now? :-)
Yes, I simply moved the comment :)


More information about the Gcc-patches mailing list