https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #10 from Andi Kleen <andi-gcc at firstfloor dot org> ---
My earlier analysis was wrong. The file cache is exactly supposed to avoid
this quadratic case.
But the cache only works if the linemap knows the total number of lines,
otherwise it uses a much slower fallback method
which ends up reparsing the line boundaries all the time and wastes all
the CPU.
But that's not the case for C because the parser runs before the file is fully
lexed.
/* This is the total number of lines of the current file. At the
moment, we try to get this information from the line map
subsystem. Note that this is just a hint. When using the C++
front-end, this hint is correct because the input file is then
completely tokenized before parsing starts; so the line map knows
the number of lines before compilation really starts. For e.g,
the C front-end, it can happen that we start emitting diagnostics
before the line map has seen the end of the file. */
I think you wouldn't see the problem with C++.
I'm not fully sure why the cache really needs the maximum number of lines,
maybe it could work without it.
Or there's already some code in input.cc to update m_total_lines from the input
file without requiring the linemap, but it's not used in the m indentation
diagnostics case.
Also it would probably be a good idea to add some tunables for the caches
(although with the problem above this doesn't fix the issue)
