https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99782
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2021-03-26 00:00:00 |2024-10-14
CC| |rearnsha at gcc dot gnu.org
Priority|P3 |P2
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
For vh < 7:
0.18user 0.01system 0:00.20elapsed 96%CPU (0avgtext+0avgdata 73576maxresident)k
8inputs+8outputs (0major+6011minor)pagefaults 0swaps
vh < 8:
0.40user 0.04system 0:00.45elapsed 99%CPU (0avgtext+0avgdata
137828maxresident)k
0inputs+8outputs (0major+14702minor)pagefaults 0swaps
vh < 9:
1.04user 0.09system 0:01.14elapsed 99%CPU (0avgtext+0avgdata
309376maxresident)k
0inputs+8outputs (0major+24603minor)pagefaults 0swaps
vh < 10:
3.21user 0.22system 0:03.44elapsed 99%CPU (0avgtext+0avgdata
735428maxresident)k
0inputs+8outputs (0major+40534minor)pagefaults 0swaps
It's not exactly clear how it gets to this runaway state but expand_ccmp_expr
is done recursively when expanding operands of outer ccmps and as that
outer ccmp expansion eventually fails - expand_ccmp_expr_1 (g, &prep_seq,
&gen_seq) always returns NULL, this ends up being exponential.
The issue is of course the "ulimited" TER we do here and the fact that
ccmp detection is so weirdly wired in rather than done pre-expansion on
GIMPLE during ISEL or so.
Richard - the Linaro folks authoring this likely no longer exist - can you
see to find somebody responsible for the ccmp infrastructure?
