diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2024-10-22 22:36:03 +0200 |
|---|---|---|
| committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2024-10-22 22:36:03 +0200 |
| commit | a6db5908a55adbef0a0dc1eb2a22743064fe17b8 (patch) | |
| tree | 19c687137250e588c3b0a00b8fee712f646a17db /gcc/testsuite/c-c++-common/init-5.c | |
| parent | 5fd1c0c1b6968d55e3f997d67a4c149edf20c012 (diff) | |
| download | gcc-a6db5908a55adbef0a0dc1eb2a22743064fe17b8.zip gcc-a6db5908a55adbef0a0dc1eb2a22743064fe17b8.tar.gz gcc-a6db5908a55adbef0a0dc1eb2a22743064fe17b8.tar.bz2 | |
c: Better fix for speed up compilation of large char array initializers when not using #embed [PR117190]
On Wed, Oct 16, 2024 at 11:09:32PM +0200, Jakub Jelinek wrote:
> 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.
Sorry for rushing the previous patch too much, turns out I was wrong,
given that the c_parser_peek_nth_token numbering is 1 based, we can peek
also with c_parser_peek_nth_token (parser, 4) and the loop actually peeked
just at 3 tokens, not 4.
So, I think it is better to revert the previous patch (but keep the new
test) and instead peek the 4th non-raw token, which is what the following
patch does.
Additionally, PR117190 shows one further spot which missed the peek of
the token after CPP_COMMA, in case it is incomplete array with exactly 65
elements with redundant comma after it, which this patch handles too.
2024-10-22 Jakub Jelinek <jakub@redhat.com>
PR c/117190
gcc/c/
* c-parser.cc (c_parser_initval): Revert 2024-10-17 changes.
Instead peek the 4th token and if it is not CPP_NUMBER,
handle it like 3rd token CPP_CLOSE_BRACE for orig_len == INT_MAX.
Also, check (2 + 2 * i)th raw token for the orig_len == INT_MAX
case and punt if it is not CPP_NUMBER.
gcc/testsuite/
* c-c++-common/init-5.c: New test.
Diffstat (limited to 'gcc/testsuite/c-c++-common/init-5.c')
| -rw-r--r-- | gcc/testsuite/c-c++-common/init-5.c | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/gcc/testsuite/c-c++-common/init-5.c b/gcc/testsuite/c-c++-common/init-5.c new file mode 100644 index 0000000..61b6cdb --- /dev/null +++ b/gcc/testsuite/c-c++-common/init-5.c @@ -0,0 +1,19 @@ +/* PR c/117190 */ +/* { dg-do run } */ +/* { dg-options "-O2" } */ + +struct S { char d[]; } v = { +{ 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + 0, } +}; + +int +main () +{ + for (int i = 0; i < 65; ++i) + if (v.d[i] != (i == 0 ? 8 : 0)) + __builtin_abort (); +} |