strange bootstrapping problems on i386-sequent-sysv4

[GNU installation owner]

In an attempt to reproduce a problem I had on another x86 platform, I
tried to bootstrap gcc-2.95.2 on a Sequent Dynix/ptx machine.  Very
different from gcc-2.8.1, I cannot bootstrap it here.

After sorting out a minor problem, (you may want to apply this patch
for the next release, probably in configure.in),

--- gcc/configure~      Wed Oct 13 07:58:02 1999
+++ gcc/configure       Fri Mar 17 09:31:37 2000
@@ -3509,7 +3509,7 @@
                ;;
        i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*)
                xm_file="xm-siglist.h xm-alloca.h ${xm_file}"
-               xm_defines="USG POSIX SMALL_ARG_MAX"
+               xm_defines="USG POSIX SMALL_ARG_MAX NO_SYS_SIGLIST"
                xmake_file=x-svr4
                tm_file=i386/ptx4-i.h
                tmake_file=t-svr4

the following problem persisted.  All three stages compile fine,
comparison 2/3 succeeds, but building the C++ libraries bombs at
libio/builtinbuf.cc, hallucinating syntax errors:

	In file included from builtinbuf.h:32,
					 from builtinbuf.cc:29:
	streambuf.h: In method `void ios::clear(int = 0)':
	streambuf.h:212: `class ios' has no member named `_throw_failure'
	streambuf.h: In method `void ios::set(int)':
	streambuf.h:214: `class ios' has no member named `_throw_failure'
	streambuf.h: In method `void ios::setstate(int)':
	streambuf.h:216: `class ios' has no member named `_throw_failure'
	streambuf.h: In method `ios::operator void *() const':
	streambuf.h:222: `class ios' has no member named `fail'
	streambuf.h: In method `int ios::operator !() const':
	streambuf.h:223: `class ios' has no member named `fail'
	streambuf.h: In method `void ios::exceptions(int)':
	streambuf.h:227: `class ios' has no member named `_throw_failure'
	streambuf.h: In method `class streambuf * ios::rdbuf(streambuf *)':
	streambuf.h:231: `class ios' has no member named `clear'

For your convenience, the first alleged error,

	#ifdef _IO_THROW
		void _throw_failure() const { throw new ios::failure(this); }
	#else
		void _throw_failure() const { }
	#endif
		void clear(iostate state = 0) {
		_state = _strbuf ? state : state|badbit;
		if (_state & _exceptions) _throw_failure(); }

which is perfectly correct C++ code, and cc1plus of an existing
gcc-2.8.1 compiles 2.95.1-generated builtinbuf.ii fine (even if
invoked by the new xgcc using -B).

I tried building cc1plus with various optimisation levels, building it
with the existing gcc-2.8.1 and even building it with the vendor's cc.
The cc1plus of the gcc-2.95.2 distribution, no matter how I build it,
is unable, on this platform, to compile builtinbuf.cc.

The system configuration has not changed since 2.8.1 was built, no new
libraries installed or the like.  The machine is an SMP with 8 plain
Pentium 100 processors, but that should not matter so much.

Any hints where to look for the error?  Any known/fixed bugs in the
symbol table lookup?  Any fixed wild pointers anywhere?  Any
importabilities in the source fixed that could have led to this
effect?  Any suspicious uses of the C library, possibly malloc?  (The
malloc of the Fortran subsystem is not being used for cc1plus, is it.)

I hope to hear something like, "oh that is probably that old bug, we
fixed it long ago; try if it goes away with [something simple] or if
you can catch it with [some debugging hint]". Meanwhile I will try to
build gdb-4.18 with gcc-2.8.1...

Cheers,
-- Marco
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email 
is strictly prohibited.
If you have received this email in error, please notify the 
Thyron IT Administrator on +44 (0)1923 236 050 or 
send an email to mail-admin@thyron.com.
Thank You