Xref: utzoo comp.unix.questions:13295 comp.unix.wizards:15956 gnu.gcc.bug:1045
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards,gnu.gcc.bug
Subject: Re: gnucc and signal 6
Keywords: gnucc signal IOT
Message-ID: <1570@auspex.auspex.com>
Date: 5 May 89 22:32:30 GMT
References: <433@brian386.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 29


 >gnucc: Program cc1 got fatal signal 6.
 >
 >I looked this up in the SDS manual, and it says that signal 6 is SIGIOT,
 >and has the ever helpful description:
 >
 >SIGIOT	06	IOT instruction
 >
 >(Thanks guys ;-)  Anyway, what is an IOT instruction and why would I be
 >getting one during a compile.
 >
 >My system is MicroPort V386r3.0e.

And the manual is being stupid.  An IOT instruction is an instruction on
the PDP-11; a routine called "abort()" in PDP-11 UNIX executed this
instruction.  That routine was to be used by programs that were "at the
end of their rope", and wanted to exit and force a core dump.  In later
UNIX releases, "abort()" just sent a SIGIOT signal to the process
itself, which means it didn't have to execute some instruction that
might not even exist.  In even later UNIX releases, such as S5R3 - upon
which the Microport release in question is, I assume, based, so I don't
understand why it doesn't follow suit here - the signal SIGIOT was
renamed SIGABRT, to reflect the fact that it now meant
"program-generated abort" rather than "IOT instruction executed".

The message means "Program cc1 came to the end of its rope and executed
'abort()' in the hopes that somebody might be able to paw through its
core dump and figure out what went wrong."  Have fun with the "core"
file....