This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: sjlj-exceptions ICE. simplified test case
- To: gcc at gcc dot gnu dot org
- Subject: Re: sjlj-exceptions ICE. simplified test case
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 26 Apr 2000 11:04:26 -0600
- Newsgroups: cygnus.egcs
- Organization: Cygnus Solutions
- References: <u9r9btferg.fsf@yorick.cygnus.com> <20000426101645.24602.qmail@pasanda.cygnus.co.uk> <20000426080315F.mitchell@codesourcery.com>
- Reply-To: tromey at cygnus dot com
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Andrew> From the gcj (Java) point of view, I most strongly object to
Andrew> this suggestion. Yes, we prefer to use range table based
Andrew> exceptions, but sjlj exceptions are a useful way to begin
Andrew> porting Java to a new target, and to remove sjlj support
Andrew> before we've ported range tables to all our targets will cause
Andrew> us great pain.
Mark> However, we should all be aware that every feature, even ones
Mark> that already exist, have a substantial maintenance cost.
Mark> Perhaps, from the point of view gcj development, sjlj exceptions
Mark> "just work". But, Richard just spent some time tracking down
Mark> bugs that only occurred in that context, and lots of other
Mark> people have had to debug similar problems in the past. Some of
Mark> those resources could probably have been devoted to implementing
Mark> the DWARF2 unwind support for a few more targets.
However, it isn't that simple either. Resources aren't really
completely fluid like that. And I gather that porting the remaining
targets to table-based exceptions isn't being done. I think Andrew's
point is that we all agree that table-based exceptions are the way to
go. But ditching them before they are more completely implemented
would be a real problem.
Tom