This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR preprocessor/15167
Eric Botcazou <email@example.com> writes:
>> I think f->buffer_valid is supposed to be reset by _cpp_stack_file.
>> How did it get this far with buffer_valid true?
> I'm not sure I understand: this is a #pragma-onced header so it cannot be
I'm looking at this bit of _cpp_stack_file:
/* Clear buffer_valid since _cpp_clean_line messes it up. */
file->buffer_valid = false;
/* Stack the buffer. */
buffer = cpp_push_buffer (pfile, file->buffer, file->st.st_size,
CPP_OPTION (pfile, preprocessed));
All #include-d files go through this code. Therefore, _cpp_pop_buffer
should never see a file with buffer_valid true. I thought (correctly)
that your test case might involve recursive includes, but that's not
enough to explain it - this happens before the file is parsed.
> Moreover, the problem is that it is included from two different
> directories, so two _cpp_file objects are allocated.
Ugh. That's not supposed to happen. (This is not your fault - the
file-cache data structure has been broken for a long time.) However,
again I don't see how it can possibly cause ->buffer_valid to be true
at the point where you are clearing it.
>> You're allowed to create a test case made up of five files (and/or
>> directories) if you need to. Several tests in gcc.dg/cpp are already
>> like that. And it would help me review this if you showed an example,
>> so that I could see how this was happening.
> OK. Attached.
Thanks. For inclusion in gcc-dg/cpp you will need to use more
distinguished names - the existing multiple include test cases are
gcc.dg/cpp/mi*.[ch], please follow that (not terribly clear, but
working) convention. There is already an "inc/" directory, which you
should use if at all possible.