need for flag for incompatible-changes

[Joe Buck]

> Joe Buck <jbuck@Synopsys.COM> writes:
> > 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 misunderstand.  I am not proposing a flag to control a specific
> set of changes.  I am proposing a flag to signal "I am not concerned
> about binary compatibility."  It is flag only intended for developers.
> Then at each "flag day" (sic) we migrate a whole bunch of changes
> from being under control of this flag, to become the default.

OK, I get what you want to do.  Unfortunately, this *still* has to be done
very carefully, or we restore the "Linux users need not apply to hack gcc"
state of affairs we had up until egcs came out (because the world breaks
if your libc and libstdc++ aren't compatible, and things like
vtable-thunks must be set the same for both).

> > 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.
> 
> No, that is just *one* of the changes,  though it is one of the more
> major and obviously incompatible ones.  I don't want a flag for each
> change.

Even though it might be convenient to have one command line flag, it's
probably best to have multiple internal flags.  Otherwise you have more
work when it's decided that three out of your five new features are good
enough to be the default -- you don't have to go searching through the
code, you just set three of the five internal flags to "enabled".