https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117177
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:96ba5e5663d4390a7e69735ce3c9de657fc543fc commit r15-4402-g96ba5e5663d4390a7e69735ce3c9de657fc543fc Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Oct 17 06:59:31 2024 +0200 c: Fix up speed up compilation of large char array initializers when not using #embed [PR117177] Apparently my c: Speed up compilation of large char array initializers when not using #embed patch broke building glibc. The issue is that when using CPP_EMBED, we are guaranteed by the preprocessor that there is CPP_NUMBER CPP_COMMA before it and CPP_COMMA CPP_NUMBER after it (or CPP_COMMA CPP_EMBED), so RAW_DATA_CST never ends up at the end of arrays of unknown length. Now, the c_parser_initval optimization attempted to preserve that property rather than changing everything that e.g. inferes array number of elements from the initializer etc. to deal with RAW_DATA_CST at the end, but it didn't take into account the possibility that there could be CPP_COMMA followed by CPP_CLOSE_BRACE (where the CPP_COMMA is redundant). As we are peaking already at 4 tokens in that code, peeking more would require using raw tokens and that seems to be expensive doing it for every pair of tokens due to vec_free done when we are out of raw tokens. So, the following patch instead determines the case where we want another INTEGER_CST element after it after consuming the tokens, and just arranges for another process_init_element. 2024-10-17 Jakub Jelinek <ja...@redhat.com> PR c/117177 gcc/c/ * c-parser.cc (c_parser_initval): Instead of doing orig_len == INT_MAX checks before consuming tokens to set last = 1, check it after consuming it and if not followed by CPP_COMMA CPP_NUMBER, call process_init_element once more with the last CPP_NUMBER. gcc/testsuite/ * c-c++-common/init-4.c: New test.
