https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- With a slightly modified testcase: #define m1(p1, p2, p3) p3 #define m2(p1, ...) 1 __VA_OPT__() #define M(...) m1(1, 2, m2) #if M(,)(,) #endif it started to ICE already with r8-6791-g60887f8c2df851 aka PR83708 fix. The r12-6155-g5545d1edcbdb17 change just turns that into the same tokens as before, while previously it wasn't. As __VA_OPT__() or __VA_OPT__(foo) in both cases expands to nothing, 1##nothing is still 1 and the avoid_paste token is added afterwards to make sure token after __VA_OPT__() isn't emitted right after it without whitespace. It isn't immediately clear to me what should be eating the padding token so that cpp_parse_expr doesn't see it. Or is this a bug in cpp_parse_expr? I mean, other callers of cpp_get_token_with_location like e.g. in c_lex_with_flags handle CPP_PADDING by calling cpp_get_token_with_location again. Similarly scan_translation_unit when doing -E, token_streamer::stream just remembers there was padding and goes on (and takes that into account whether whitespace should be emitted or not).