RE: Problem w/PIC and C++ exceptions in 2.95 on IA-32

["Eric Dana" <eric_dana at bmc dot com>]

I've been trying to build 2.95.2 for the Sequent (Dynix 4.4.2-4.4.6)
and it fails to build when it encounters class ios.

In class ios, any member function that is defined in the class and
then subsequently used in the class is not found in the class.
This occurs when, in stage 3, libio/builtinbuf.h is referenced.

This has occured since egcs 1.1.2 (1.1.1 and earlier built just fine
after makaing sure follwing was defined [xm-siglist.h is included
by default and is incorrect]:

/* DYNIX/ptx provides no sys_siglist.  */
#undef SYS_SIGLIST_DECLARED
#define NO_SYS_SIGLIST 1

so collect2.c builds correctly.

And gcc 2.96 snapshots segfault while building, a gcc 2.95.3 would be
of use to my company (unless a working, released version 2.96 is coming
soon).

Eric Dana
BMC Software Inc.

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Marc Espie
> Sent: Thursday, January 20, 2000 1:36 PM
> To: jbuck@synopsys.COM
> Cc: egcs@egcs.cygnus.com
> Subject: Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32
>
>
> In article <867j5t$hh2$1@clipper.ens.fr> you write:
> >> > > 2000-01-03  Anthony Green  <green@cygnus.com>
> >> > >
> >> > > 	* config/i386/i386.md (builtin_setjmp_receiver):
> New pattern.
> >> > > 	Restore the pic register if required.
>
> >On Thu, Jan 20, 2000 at 09:37:25AM -0800, David O'Brien wrote:
> >> > Would it *PLEASE* :-)) be possible to commit it to the 2.95 branch?
>
> >Richard Henderson writes:
> >> Done.
>
> >This only matters if we plan on issuing 2.95.3.  Do we have sufficient
> >minor bugs to justify that?
>
> I can understand not wanting to ship `release of the day', but this
> single bug does look obnoxious enough to justify 2.95.3.
>
> Of course, this does depend heavily on what plans there are to go ahead
> and manufacture a new release in the reasonable future... so far,
> I haven't
> seen any hint that things are going to stabilize over the next
> three months.
>
> Upgrades should go like this, in my opinion: decide on a minimum interval
> between releases (say, two months).
>
> Each time the interval has elapsed, if you've got any real bugs, then you
> should crank out a new release.
>
> I don't know about you, but a bug which thoroughly breaks any real world
> C++ application on any i386 platform with sj-lj exceptions is real enough.
>