On Sun, 26 Jul 2026, Arsen Arsenović wrote: > When a subprocess (say, lto1) gets killed by SIGKILL on Linux with > LANG=en_..., the message GCC prints is "Killed signal terminated program > lto1". > > This message is a little bit unclear - the "Killed" is certainly not > something that gramatically fits there, and the syscall for sending a > signal is called "kill", so the above sounds like an incorrect way of > saying "program lto1 was killed by some signal". > > I can't find any decent description of what the correct class of words > strsignal returns, so, lets instead print "PROG killed by signal
"PROG terminated by" (not "killed", to match the actual change) > 9 (Killed)". This is clearer; it states that signal 9 is at fault and > gives the OS-provided "descriptive string" corresponding to that signal. > > Example: > > ~/gcc/_b_gcc/gcc$ ./xgcc -B. -x c - > xgcc: fatal error: cc1 killed by signal 9 (Killed) Ditto here. > compilation terminated. > ~/gcc/_b_gcc/gcc 1 $ > > gcc/ChangeLog: > > * gcc.cc (execute): Make "signal terminated program" message > clearer. > > Suggested-by: Alexander Monakov <[email protected]> > --- > Tested on x86_64-linux-gnu, including by running the test xgcc command > above and SIGKILL-ing cc1. OK for trunk? > > gcc/gcc.cc | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gcc/gcc.cc b/gcc/gcc.cc > index b8b0db4ed5e4..a0afb38cdc9a 100644 > --- a/gcc/gcc.cc > +++ b/gcc/gcc.cc > @@ -3563,7 +3563,9 @@ execute (void) > thinking there's a compiler bug. Much more likely is > the user or OOM killer nuked it. */ > fatal_error (input_location, > - "%s signal terminated program %s", > + "%s terminated by signal %d (%s)", > + commands[i].prog, > + WTERMSIG (status), > strsignal (WTERMSIG (status)), > commands[i].prog); The last argument (commands[i].prog) should not be there (doesn't it trigger a warning?) Do we want (%qs) instead of (%s) for signal string so it's formatted in quotes? Thanks for sending this! Alexander
