This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH to c-commonc.c, preliminary for PR/3865 fix
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>,gcc-patches at gcc dot gnu dot org
- Date: Sun, 1 Sep 2002 12:45:29 -0700
- Subject: Re: PATCH to c-commonc.c, preliminary for PR/3865 fix
- References: <m3bs7oy7vo.fsf@soliton.integrable-solutions.net> <20020830201817.GE1862@codesourcery.com> <m3bs7k5anu.fsf@soliton.integrable-solutions.net> <20020831042229.GA321@codesourcery.com> <20020831072432.GA23528@daikokuya.co.uk> <20020831183225.GK321@codesourcery.com> <20020831191042.GA582@daikokuya.co.uk>
On Sat, Aug 31, 2002 at 08:10:42PM +0100, Neil Booth wrote:
> > It's an interesting idea. Didn't we have problems with that kind of
> > optimization before? That was with macros defined to the empty
> > string, though, maybe defined to a single token wouldn't be as much of
> > a problem.
> >
> > I was mainly thinking about reducing initialization overhead, not
> > macro expansion overhead.
>
> I think you misunderstood. I _was_ talking about init overhead; we
> still have to push, lex and pop the string buffer.
Oh. Yes, I misunderstood. This would end up creating the normal data
structure for a preprocessor macro, just short circuit the process?
Sounds like a good idea.
zw