This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ PATCH: Fix PR 862


>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

>>>>> "Jason" == Jason Merrill <jason_merrill@redhat.com> writes:
Jason> I would doubt that, but in any case I don't think the
Jason> specific degree of brokenness is the issue; I don't see the
Jason> problem with having flags for functionality that is still
Jason> under development.  -fnew-abi comes to mind.  Or, more
Jason> similarly, -fssa.

> True -- for the development mainline.  I think there's little point in
> having known broken flags (like -fssa) in releases.  In fact, that
> reminds me that -fssa should probably go away on the branch.  I think
> from what you say that you agree, right?

Yes.

> I think we should document flags in invoke.texi the moment they go
> into the compiler.  If nothing else, that will force us to clearly
> define what the purpose of the option is, in English.  If we can't do
> that, then the option is not even ready to be in the development
> stage.

I agree for flags (such as -fvtable-gc) that are intended to be used by
users one day.  I don't know that I agree for flags that are merely a
development convenience.  For instance, to switch on and off a piece of
code that some day should be always on, as with -fnew-abi.

But if you feel strongly about it, I'll concede the point.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]