Re: need for flag for incompatible-changes

[Joe Buck <jbuck at synopsys dot com>]

> The problem:  We need to continue to make changes to gcc exception
> handling, mangling, etc.  Some of these will be incompatible changes.

> We could use -fexperimental-exceptions to enable compatibility-breaking
> eh-related changes.  Or we could use a more general flag -fexperimental
> as a catch-all.

But there will be problems if you do more than one round of this: first
-fexperimental-exceptions, then that becomes the standard, and then you
want to do a new round of experimental exceptions.

You need to give each incompatible feature a more specific name.  You
can't pollute the name space by taking "experimental exceptions" unless
you assume that no one else will ever make a different experiment.

> How about -fno-compatibility?

I think that that is even worse.  Many possible changes can break
compatibility.

In your case, the change you propose is to add a fourth field to the
exception table, so ideally the flag should suggest precisely that.
Good abbreviations are hard to come by:
-fexceptions-with-handler-type is a bit wordy.
We could name it after you: -fexceptions-bothner98 (this lets you
do a different scheme next year :-).