This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.
- From: Christian Jönsson <christian at j-son dot org>
- Cc: "'gcc'" <gcc at gcc dot gnu dot org>
- Date: Sun, 22 Sep 2002 21:10:02 +0200
- Subject: RE: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.
Hmm, for some reason, it bootstraps right now.... Just the last few
days...
Oh well, great I guess..
Will post testsuite results soon... Tomorrow morning I guess...
Cheers,
/ChJ
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
'Neil Booth'
Sent: Thursday, September 12, 2002 10:06 AM
To: Zack Weinberg
Cc: 'gcc'
Subject: Re: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168:
error: parse error before ']' token etc.
Zack Weinberg wrote:-
> > I figure that if we made a token's "col" mean "logical character on
> > a physical line", we could have a fairly simple loop that
> > understands trigraphs that selects the right point. If, in the
> > caret line, we replace every character of the original line with a
> > space (except tabs) we will get the same location for output (with
> > some handling of multibyte chars when we support them).
>
> I'm not sure I understand the context in which you propose this
> solution. Can you expand a bit?
Sorry I was unclear. Any context in which we pre-scan the line removing
trigraphs and escaped newlines.
> It occurs to me that the prime difficulty with reading the file in
> chunks, independent of whether we have a prescan pass, is the (common
> but not normal) situation of having a line cross a chunk boundary. We
> could deal with that by scanning backward from the end of the chunk
> for the last newline. Put the limit pointer there. Then we only have
> to check the limit pointer at newlines, and when we hit it we can just
> copy the trailing text down to the front of the buffer and keep
> reading.
Yes. You might be able to just terminate the chunk with NUL and lex
like we do now. You just need to be able to back up over the previous
token when you reach the NUL, since it might have been prematurely
terminated. This means you have to be careful about issuing diagnostics
too early, in case they were caused by the premature NUL.
> If the file has a single line longer than the chunk size we have to
> resize the buffer, but we'd have to do that anyway.
Neil.