https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106359
Bug ID: 106359
Summary: -fanalyzer takes a very long time on Linux kernel:
sound/soc/codecs/cs47l{85,90}.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
Target Milestone: ---
I've been testing -fanalyzer trunk with my trust boundaries patches on the
upstream Linux kernel, with "allyesconfig".
-fanalyzer seems to take a *very* long time on:
sound/soc/codecs/cs47l85.c and sound/soc/codecs/cs47l90.c (admittedly with a
debug build of gcc).
I saw it take roughly 4 hours to analyze the former, and I stopped the latter
after four hours to investigate with gdb.
The latter had:
(gdb) p *eg.m_nodes.m_vec
$4 = {m_vecpfx = {m_alloc = 609, m_using_auto_storage = 0, m_num = 408},
m_vecdata = {0x611a7e0}}
(gdb) p *eg.m_edges.m_vec
$5 = {m_vecpfx = {m_alloc = 609, m_using_auto_storage = 0, m_num = 427},
m_vecdata = {0x6265af0}}
which is reasonable, but:
(gdb) p m_store.m_cluster_map
$9 = {m_table = {m_entries = 0xadc1260, m_size = 262139, m_n_elements = 144088,
m_n_deleted = 0, m_searches = 1008610, m_collisions = 534316,
m_size_prime_index = 15, m_ggc = false, m_sanitize_eq_and_hash = true,
static m_gather_mem_stats = false}}
which is a ludicrously large number of clusters in the store, and thus
presumably responsible for the slowdown.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer
