need for flag for incompatible-changes
Joe Buck
jbuck@synopsys.com
Tue Jan 27 16:52:00 GMT 1998
> 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 :-).
More information about the Gcc
mailing list