https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121508
Léo Hardt <leom.hardt at inf dot ufrgs.br> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |leom.hardt at inf dot ufrgs.br
--- Comment #3 from Léo Hardt <leom.hardt at inf dot ufrgs.br> ---
Hello, everyone,
Here are some smaller code variations which also cause the same crash:
(A)
int i = __has_include(<__int16_t
(B)
int i = __has_include(<__int16_t)
(C)
int i = __has_embed(<__int16_t
(D)
int i = __has_embed(<__int16_t)
(E)
int i = __has_embed(<__int16_t + 1 + 2 + 3
Notice that both "builtin_has_include" and "builtin_has_embed" share code in
"builtin_has_include_1".
For the case "A" above:
The last token of the file is read inside 'builtin_has_include_1', and then:
1. _cpp_lex_token returns EOF
2. _cpp_pop_buffer is called.
Since we reached the end of the user-supplied file, now, pfile->buffer is
null.
3. builtin_has_include_1 returns the name of the parameter correctly as
"__int16_t".
4. Since builtin_has_include_1 returns a valid string, builtin_has_include
thinks
parsing is going normally, and tries to fetch the closing parenthesis token.
5. Since we are trying to get a new token, but pfile->buffer is already null,
we encounter an ICE on the line
if (paren
&& _cpp_get_token_no_padding (pfile)->type != CPP_CLOSE_PAREN)
The quickest possible fix is to add "&& pfile->buffer" to the condition above.
Perhaps it would also be good to add a "gcc_assert(pfile);
gcc_assert(pfile->buffer)" to _cpp_lex_direct as well.
