On Wed, Sep 30, 2026 at 05:57:29PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 29, 2026 at 04:58:39PM -0300, Léo Hardt wrote:
> > I'm currently trying to look into libcpp more deeply
> > before submitting a patch to fix it and break another
> > behaviour again.
>
> I have looked at it more closely today and I think we should
> go for the following patch (thouch so far just lightly tested
> with
> GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,29 make check-gcc check-g++ -j32 -k
> RUNTESTFLAGS="dg.exp='cpp/*' cpp.exp gomp.exp"
> and will test it properly overnight).
>
> I'm guilty of introducing _cpp_get_token_no_padding 6 years ago
> instead of fixing up get_token_no_padding back then, I wasn't
> sure if the eating of CPP_EOF wasn't intentional in some cases,
> but clearly it is never intentional and always a bug.
> After all, get__Pragma_string has been fighting with it already
> by using
> paren = get_token_no_padding (pfile);
> if (paren->type == CPP_EOF)
> _cpp_backup_tokens (pfile, 1);
> glue_header_name and parse_include weren't doing this, but in
> the usual case when pfile->state.in_directive and not lexing a raw string,
> get_fresh_line_impl returns false and _cpp_lex_direct will just keep
> returning CPP_EOF at the end of the line many times until we clear
> the pfile->state.in_directive flag.
> So, I think we should just drop the dangerous get_token_no_padding
> function and simply never eat a CPP_EOF.
Bootstrapped/regtested successfully on x86_64-linux and i686-linux,
ok for trunk?
Jakub
