EH bug in Makefile.in

[Mumit Khan]

Joe Buck <jbuck@synopsys.com> writes:
> 
> Yes, I've just confirmed this (well, my gas, from 2.8.0.1.15, calls
> itself 970731: is this what you meant?).

I'm actually using the binutils-971023 snapshot from cygnus. Probably
not a whole lot different from 2.8.0.1.15, considering how fast HJ 
updates these things. I needed the 971023 snapshot to get egcs working
for i386-cygwin32 target and it works great (thanks to Ian Taylor for
the pointer to dev snapshot).

> 
> Pretty impressive!  Question though: do folks think MRS's exception tests
> cover the problem areas well, or are there other failure modes (someone
> mentioned that delete is not called if a contructor for an object
> allocated by new throws an exception, are there others?)?
> 

I'm going to test some of my code tomorrow which does some of what you
mention. Currently only a few compilers handle it correctly -- some EDG
based ones (eg., Kai) and Intel's C++. I'll post results.

> As you know, I've been eager to permit use of egcs on older Linux systems
> with the egcs compiler installed in a different directory (I use
> /usr/local/egcs as prefix).  I'm willing to accept dropping in a new gas
> to do this (I built mine without enable-shared so I just have one file to
> deal with, at least until I upgrade the whole system).  If it were trivial
> to modify things so that an older gas would work as well, that would be
> nice but it should be low priority.

After suffering thru the older gas on both linux and i386-cygwin32, I'm
not so sure that it's worth the backward compatibility. We're already
doing this for other platforms (eg., --with-gnu-as under hpux to get
debugging info), so it's probably not a big deal.

One wish I have now is that g++ team revisit the question of name mangling
again. Try blitz++ (and some of my own code) to see why it's becoming
unmanagable -- the symbol lengths are just too damn long. I just noticed
that you reposted your proposal. Let's see what happens.

Mumit