From mboxrd@z Thu Jan 1 00:00:00 1970 From: jbuck@synopsys.com (Joe Buck) To: bothner@cygnus.com (Per Bothner) Cc: egcs@cygnus.com Subject: Re: need for flag for incompatible-changes Date: Tue, 27 Jan 1998 19:15:00 -0000 Message-id: <9801280201.AA19159@belgarath.synopsys.com> References: <199801280102.RAA05676@cygnus.com> X-SW-Source: 1998-01/msg01022.html > Joe Buck 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".