https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:49e320ac0792672e2137ca47215fd7f935302895 commit r11-10072-g49e320ac0792672e2137ca47215fd7f935302895 Author: Jakub Jelinek <ja...@redhat.com> Date: Sun May 29 21:57:51 2022 +0200 libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732] The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is nothing afterwards, true). In most cases these CPP_PADDING tokens don't matter, all other callers of cpp_get_token_with_location either ignore CPP_PADDING tokens completely (e.g. c_lex_with_flags) or they just remember them and take them into account when printing stuff whether there should be added whitespace or not (scan_translation_unit + token_streamer::stream). So, I think we should just ignore CPP_PADDING tokens the same way in _cpp_parse_expr. 2022-05-27 Jakub Jelinek <ja...@redhat.com> PR preprocessor/105732 * expr.c (_cpp_parse_expr): Handle CPP_PADDING by just another token. * c-c++-common/cpp/va-opt-10.c: New test. (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)
