sjlj-exceptions ICE. simplified test case

[Mark Mitchell]

--On Wednesday, April 26, 2000 11:04:26 AM -0600 Tom Tromey 
<tromey@cygnus.com> wrote:

>>>>>> "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.

Wow, I don't really remember this conversation.  Yes, there is clearly
a tension between inconveniencing people whose targets currently only
do SJLJ and the people who have to maintain SJLJ, or touch code where
it shows up.  It's a balancing act...

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com