Re: "macros nested too deep" problem in ss-20000724 (and recent)

Re: "macros nested too deep" problem in ss-20000724 (and recent)

[Mike Stump]

> From: "Thomas R. Truscott" <trt@cs.duke.edu>
> To: gcc-bugs@gcc.gnu.org
> Date: Tue, 25 Jul 2000 18:23:35 -0400 (EDT)

> Starting sometime this year (and including ss-20000724),
> the pre-processor has had a nested macro limit of about 200.
> Before that it had a limit of about 400.
> The smaller limit causes a number of compile failures
> in a large software product:

:-(

I think that we should add a zero (or two).  That should be good for
another decade or so.  At that time, we can revisit adding another
zero or two.  :-)

> Our fix was is to increase CPP_STACK_MAX in cpplib.h
> 	#define CPP_STACK_MAX 1000
>From aoliva@redhat.com Tue Jul 25 18:55:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Henderson <rth@cygnus.com>
Cc: Toshiyasu Morita <tm@netcom.com>, gcc-bugs@gcc.gnu.org, Jorn Wolfgang Rennecke <amylaar@cygnus.com>, gcc-patches@gcc.gnu.org
Subject: Re: (i386-linux x sh-elf) build breakage
Date: Tue, 25 Jul 2000 18:55:00 -0000
Message-id: <orpuo1slif.fsf@guarana.lsd.ic.unicamp.br>
References: <200007112040.NAA06981@netcom.com> <20000717170342.A13413@cygnus.com> <oru2dl17xk.fsf@guarana.lsd.ic.unicamp.br> <20000725114629.C23874@cygnus.com>
X-SW-Source: 2000-07/msg00659.html
Content-length: 1780

On Jul 25, 2000, Richard Henderson <rth@cygnus.com> wrote:

> On Thu, Jul 20, 2000 at 06:12:55AM -0300, Alexandre Oliva wrote:
>> +      printf ("#define INSN_ADDRESSES_DEFN() varray_type insn_addresses_\n");

> I don't like this.  You should just declare the thing
> in final.c and be done with it.

I wanted to completely abstract away its type, so that it could be
changed to something else in a single place.

For example, then we could add a #define for machines that needs the
ability to add new insns to insn_addresses, and use a plain array
otherwise.

>> +      printf ("#define INSN_ADDRESSES_PUSH(v) VARRAY_PUSH_INT (insn_addresses_, (v))\n\n");

> This must be wrong, since there's no correspondence to the UID
> of the insn for which you are adding the address.

> Hum.. I see you've fudged it, but I still don't like it.  You
> might as well just resize the array and assign the new entry.

Since it would have been an error to do it after insn_addresses is
constructed, I thought it would be fine.  Maybe I should add one
argument to INSN_ADDRESSES_PUSH, with the UID of the new insn (or the
insn itself).  The idea is to help catching as soon as possible the
creation of insns without additions to INSN_ADDRESSES.


BTW, I've just found an error in the patch, while building on a target
that doesn't HAVE_ATTR_length: INSN_ADDRESSES_FREE had to be
`#ifdef'ed away, and `INSN_ADDRESSES_DEFN()' was parsed as a
function declaration :-)

With these corrections, ok to install?

-- 
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