public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Christian Jönsson" <christian@j-son.org>
Cc: "'gcc'" <gcc@gcc.gnu.org>
Subject: RE: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.
Date: Sun, 22 Sep 2002 14:00:00 -0000	[thread overview]
Message-ID: <001401c2626b$ab6aa170$0301a8c0@D90V2D0J> (raw)
In-Reply-To: <20020912080545.GA28623@daikokuya.co.uk>

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.


  parent reply	other threads:[~2002-09-22 19:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-18  7:42 Christian Jönsson
2002-08-18  7:53 ` Christian Jönsson
     [not found] ` <000b01c246c7$368d95c0$0301a8c0@D90V2D0J>
2002-08-21  7:03   ` Christian Jönsson
2002-08-27  9:33     ` Christian Jönsson
2002-08-27  9:57       ` Neil Booth
2002-09-01  8:29         ` Christian Jönsson
2002-09-03 12:54         ` Neil Booth
2002-09-04 11:57           ` Christian Jönsson
2002-09-04 12:44             ` 'Neil Booth'
2002-09-05 11:01               ` Zack Weinberg
2002-09-05 11:05                 ` 'Neil Booth'
2002-09-10 16:56                   ` Zack Weinberg
2002-09-10 23:42                     ` 'Neil Booth'
2002-09-11 13:18                       ` Zack Weinberg
2002-09-11 14:32                         ` 'Neil Booth'
2002-09-11 16:02                           ` Zack Weinberg
2002-09-12  1:05                             ` 'Neil Booth'
2002-09-18 14:18                               ` Zack Weinberg
2002-09-22 14:00                               ` Christian Jönsson [this message]
2002-10-04 13:14                                 ` Neil Booth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001401c2626b$ab6aa170$0301a8c0@D90V2D0J' \
    --to=christian@j-son.org \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).