This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 69793 ("ICE on invalid code in "cp_lexer_peek_nth_token"")
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>, Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 18 May 2016 11:29:36 -0400
- Subject: Re: [C++ Patch] PR 69793 ("ICE on invalid code in "cp_lexer_peek_nth_token"")
- Authentication-results: sourceware.org; auth=none
- References: <573B835E dot 3020706 at oracle dot com> <aa5fb55e-3831-f592-8fd7-cbffa6425965 at redhat dot com> <573C84A4 dot 9020702 at oracle dot com>
On Wed, 2016-05-18 at 17:05 +0200, Paolo Carlini wrote:
> Hi,
>
> On 18/05/2016 16:39, Jason Merrill wrote:
> > On 05/17/2016 04:47 PM, Paolo Carlini wrote:
> > > this ICE during error recovery exposes a rather more general
> > > weakness:
> > > we should never call cp_lexer_peek_nth_token (*, 2) when a
> > > previous
> > > cp_lexer_peek_token returns CPP_EOF.
> >
> > Hmm, that seems fragile, I would expect it to keep returning EOF.
> Indeed. I didn't explain myself well enough. I meant something along
> the
> lines: outside this specific and minor case of ICE during error
> recovery, we should audit our code and keep in mind that calling
> cp_lexer_peek_nth_token (*, anything > 1, the common case) right
> after
> cp_lexer_peek_token is, how shall I put it, "suspect", due to that
> assert at the beginning of cp_lexer_peek_nth_token.
Thinking aloud, I wonder if a plugin could detect this kind of thing? -
verify that any call of cp_lexer_peek_nth_token for N > 1 happens after
the result of cp_lexer_peek_token has been checked for EOF.
(another idea might be a fault-injection option for the C++ frontend,
perhaps simulating EOF at a given token index, and then using this,
somehow, to torture-test the existing test cases, but that seems like a
*lot* of extra parsing; static checking seems more efficient).