g++ memory bug.
Thu Jan 7 23:26:00 GMT 1999
>>>>> "Mike" == Mike Stump <firstname.lastname@example.org> 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 email@example.com
Mark Mitchell Consulting http://www.markmitchell.com
More information about the Gcc-patches