https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110558
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Lewis Hyatt <lhy...@gcc.gnu.org>: https://gcc.gnu.org/g:942497ad74272e0ef16020d628e471c5f21474b0 commit r14-9465-g942497ad74272e0ef16020d628e471c5f21474b0 Author: Lewis Hyatt <lhy...@gmail.com> Date: Tue Dec 12 17:46:36 2023 -0500 libcpp: Fix macro expansion for argument of __has_include [PR110558] When the file name for a #include directive is the result of stringifying a macro argument, libcpp needs to take some care to get the whitespace correct; in particular stringify_arg() needs to see a CPP_PADDING token between macro tokens so that it can figure out when to output space between tokens. The CPP_PADDING tokens are not normally generated when handling a preprocessor directive, but for #include-like directives, libcpp sets the state variable pfile->state.directive_wants_padding to TRUE so that the CPP_PADDING tokens will be output, and then everything works fine for computed includes. As the PR points out, things do not work fine for __has_include. Fix that by setting the state variable the same as is done for #include. libcpp/ChangeLog: PR preprocessor/110558 * macro.cc (builtin_has_include): Set pfile->state.directive_wants_padding prior to lexing the file name, in case it comes from macro expansion. gcc/testsuite/ChangeLog: PR preprocessor/110558 * c-c++-common/cpp/has-include-2.c: New test. * c-c++-common/cpp/has-include-2.h: New test.
