public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-12 11:58 ` jakub at gcc dot gnu.org
2021-06-01 8:11 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-12 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.3 |9.4
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow jakub at gcc dot gnu.org
@ 2021-06-01 8:11 ` rguenth at gcc dot gnu.org
2022-05-27 8:19 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-01 8:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.4 |9.5
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow jakub at gcc dot gnu.org
2021-06-01 8:11 ` rguenth at gcc dot gnu.org
@ 2022-05-27 8:19 ` rguenth at gcc dot gnu.org
2024-09-16 18:23 ` dmalcolm at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-27 8:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.5 |---
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2022-05-27 8:19 ` rguenth at gcc dot gnu.org
@ 2024-09-16 18:23 ` dmalcolm at gcc dot gnu.org
2024-09-16 18:24 ` dmalcolm at gcc dot gnu.org
2024-09-17 16:38 ` hubicka at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2024-09-16 18:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
--- Comment #15 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Brainstorming some ideas here:
LSP has an interface for reporting progress notifications; see:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workDoneProgress
The various programs launched by the driver could report back to it with
progress notifications (maybe via a unix domain socket specified via an
environment var?)
Presentation: the driver could see if it's connected to a TTY and if things are
taking above a threshold start displaying/refreshing a line showing the
progress information, perhaps e.g.:
[====== ] 50% : cc1: expand: some_function_name
showing estimated overall % complete; what current tool is, for cc1 what
current pass and funtion is; or somesuch. Maybe show:
- wallclock time elapsed
- number of "items" done vs overall number of "items" to be done (hence able to
show %), where what an "item" is would vary
Or the driver could re-report the notifications back to another LSP consumer
(e.g. an IDE, or to "make")
Could have some kind of rate-limiting on the IPC so that we're sending IPC
across the protocol at a time-based frequency, rather than doing it for every
(pass,function) pair, since that would presumably introduce lots of overhead.
Could have gcc driver, cc1 etc, gas, ld, LTO all co-operate in this so that
e.g. the user gets meaningful progress information on a big LTO compile. Maybe
event teach GNU "make" about this, so that the user can receive "integrated"
progress reports from a parallel make. (If so, probably want the protocol to
support parallel work)
(this is just a brainstorm; no guarantees about implementing any of this)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2024-09-16 18:23 ` dmalcolm at gcc dot gnu.org
@ 2024-09-16 18:24 ` dmalcolm at gcc dot gnu.org
2024-09-17 16:38 ` hubicka at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2024-09-16 18:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|1 |0
Status|ASSIGNED |UNCONFIRMED
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2024-09-16 18:24 ` dmalcolm at gcc dot gnu.org
@ 2024-09-17 16:38 ` hubicka at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: hubicka at gcc dot gnu.org @ 2024-09-17 16:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
For LTO linking we do have some idea about progress during ltrans since we
compute estimated sizes of functions and we know the size of whole unit we
build. WPA stage can at least be divided into few steps (i.e. streaming in
where we know size of input files, inlining and stream out)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-09-17 16:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-85716-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 11:58 ` [Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow jakub at gcc dot gnu.org
2021-06-01 8:11 ` rguenth at gcc dot gnu.org
2022-05-27 8:19 ` rguenth at gcc dot gnu.org
2024-09-16 18:23 ` dmalcolm at gcc dot gnu.org
2024-09-16 18:24 ` dmalcolm at gcc dot gnu.org
2024-09-17 16:38 ` hubicka at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).