I've fixed the bug, and a Hurd all compiled with gcc-2.95.2 now runs fine.
It turns out there was no particularly interesting reason gcc-2.95.2
exposed this bug, it was just the luck of the optimizer. The bug was that
in the create_startup_proc case, where allocate_proc is called with
MACH_PORT_NULL, it called mach_port_request_notification but didn't check
its return value to see that it had failed. The failing call doesn't set
the result parameter FOO, so it is some random word from the stack, which
is then passed to `mach_port_deallocate'. Previously it happened to be
zero or some other harmless value; now it happens to be 3, which happens to
just about always be the value of `mach_task_self ()', and hilarity ensues.
I added the missing error checking, and also rearranged the code so that it
won't elicit the error. While I was at it, I made it do the proper
notification request after it gets the startup_proc task port, so proc will
notice when init dies (not that it will do anything useful with the knowledge).
