Re: g++ memory bug.

[mrs at wrs dot com (Mike Stump)]

> To: mrs@wrs.com (Mike Stump)
> Date: Thu, 21 Jan 1999 01:23:58 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

>   In message <199901181801.KAA09621@kankakee.wrs.com>you write:
>   > This is a departure from the semantics that gcc had in the past. I
>   > didn't want to depart from those semantics without a very good reason.
>   > In the absense of such a reason, I don't think we should, so that we
>   > retain as much the sameness of gcc as we can.  Could you say more on
>   > why this is the right decision?
> What particular semantics are you talking about?

If a tree was marked with DECL_INLINE, we didn't hit:

  if (!DECL_INLINE (fndecl) && get_max_uid () > max_insns)
    {
    return "function too large to be inline";

in integrate.c.  My change is to place a limit even on those, but that
limit isn't the normal `small' (64) limit, but rather, a larger, more
a reasonableness (<10000) test.  We could place a small limit on those
to be symmetrical with the normal case, but that is then a decision to
be different, and I just want to ensure it is a decision and not an
accident.  I can't claim to have thought long and hard about it, so by
default, I'm in preserve old semantics mode.

If you want inline to be more of a hint from the user and less of a
semantic with meaning, then so limiting it (smaller) is a good change.