[Bug other/85716] New: No easy way for end-user to tell what GCC is doing when compilation is slow

["dmalcolm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716

            Bug ID: 85716
           Summary: No easy way for end-user to tell what GCC is doing
                    when compilation is slow
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

From #gcc on freenode:

<PlasmaHH_> Hi, I just refactored some of my code and now gcc won't finish
compiling and grows in memory size (18gig so far after 30 minutes) and I would
like to know what it is doing there. Likely something is going on with some
template instantiations or so, is there any sane debugging option that will
tell what it does on a somewhat high level while going along?
* PlasmaHH_ is now known as PlasmaHH
<dmalcolm> PlasmaHH: -ftime-report would probably be the first thing to try
<PlasmaHH> dmalcolm: those seem to output only something after they are done,
which doesn't seem to finish. at least it doesn't output anything here.
<dmalcolm> hmmm
<dmalcolm> maybe -Q then
<PlasmaHH> dmalcolm: I was afraid you come up with that, its tons of
information and all on one line ^^ which is why I was looking for a somewhat
abstract level... but guess there isn't much then...
<dmalcolm> PlasmaHH: maybe there is something, and I'm just not thinking of it.
 Seems to me like a valid thing to be able to "ask the compiler" about.
<PlasmaHH> dmalcolm: maybe that giant amount of (to me) unreadable output of -Q
is just a consequence of something going wrong...
<dmalcolm> PlasmaHH: if there were linebreaks, would it be more readable?
<dmalcolm> (my job is improving GCC usability, so it's a serious question)
<PlasmaHH> dmalcolm: definetly. since it seems to output every function... I
tried to split on ) but thats not too good for when there is a ) in the
function signature or so
<dmalcolm> PlasmaHH: I think I'll open a BZ about this for GCC 9; it seems like
there's room for improvement here
<PlasmaHH> most of the part (where things get wrong) seem to be really weird,
probably functors being passed to functors ad inf. so if they were on one line
I could much easier see that its indeed one big functor, at the moment its just
a big mess :/
<PlasmaHH> taking things apart a bit the signature of one function is so far
mentioned 184049 times in that -Q dump, possibly at various recursion
depths....
<PlasmaHH> that doesnt sound good
<dmalcolm> perhaps a infinite recursion bug, or perhaps some kind of
exponential template expansion?


As noted above, I'm capturing this in BZ as it seems like there's room for
improvement here.

Am I missing something, or is there no "easy" way (for some definition of
"easy") for an end-user to track what GCC is doing during a very long compile?

Some "brainstorm"-ish ideas:

Should -Q add newlines?
Maybe with timestamps?
Maybe a option to have some kind of timestamp-based logging, emitting a series
of lines of the form:
  [TIMESTAMP] Doing something
perhaps piggy-backing off of the timevar hooks, so that if something within GCC
goes off into the weeds, the user can see e.g. which function it's having
trouble with.