On Wed, 16 Oct 2024, Jakub Jelinek wrote: > Hi! > > 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. > > Ok for trunk if this passes bootstrap/regtest?
OK. -- Joseph S. Myers josmy...@redhat.com
