g++ memory bug.

Mark Mitchell mark@markmitchell.com
Thu Jan 7 23:26:00 GMT 1999

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    Mike> them as if inline was specified.  Something here is wrong.
    Mike> We can either default flag_default_inline to off, and let

I don't think this is a good idea at all.  It's long been understood
that writing in-class definitions is the same as out-of-class with
`inline', *whatever* that means; your patch would change this

    Mike> we can put a artificial limit on the size of a function to
    Mike> inline even when they are `inline'.  

That seems much better.  After all, inline is a hint; we can
reasonably decide that a too-big function should not be inlined. 

IMO, all such limits should be user-configurable.  I'm always
distressed to see things like the following (made-up) code:
  /* If there are more than 2000 instructions, don't inline this
     function.  That's too big to be worth inlining.  */
  if (num_insns > 2000)

since the user should be able to control that.  Sometimes, it might
still be worth it to inline these things.  Thus, ideally, all such
hard-limits should be controllable (-finline-limit=10000).  It's not
necessary that the numbers map to obvious concepts, but bigger numbers
should mean inline strictly more things.  That way users can
experiment to get the compilation-time/code-quality tradeoff they

Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

More information about the Gcc-patches mailing list