This is the mail archive of the gcc@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: RFA: Deprecate C++ options


>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

> Support of old ARM conformant code
> -fno-for-scope
> 	the for loop variable's scope extends beyond the loop

The default tries to support both new and old semantics, with a warning if
code depends on the old semantics.  This seems ideal to me; I don't much
care if -fno-for-scope goes away, so long as the default stays the same.

In general, I feel strongly that we should accept old code with a pedwarn
if at all reasonable.  If that is for some reason not feasible, such as a
conflict between old and new semantics, then I can accept breaking old code
with helpful comments to suggest how the user ought to fix their code.  I
am against just removing previous functionality and leaving users to wonder
why their code doesn't work anymore.

> -fcheck-new
> 	cope with operator new returning null, rather than throwing
> 	The interaction of this with the builtin operator new and
> 	-fno-exceptions confuses users.

I think the confusion is that -fno-exceptions should set flag_check_new,
and it currently doesn't.  But I haven't seen any messages about this.

> -fno-operator-names
> 	don't have `and' `or' etc as keywords

This seems harmless; I don't see any need to remove it.

> Bug workaround. Are there many access control bugs? I can't recall any
> in GNATs off hand.
> -fno-access-control
> 	don't check access

This also seems harmless.

> Unknown.
> -fno-elide-constructors
> 	don't elide copy ctors What is the rationale for this? I'd've
> 	thought -O0 would be a suitable switch for this.

Most optimizations can be controlled by flags other than -On.  Why not this
one?  I have considered that perhaps this optimization should be off
at -O0, but it's standard enough that I think it should always be on by
default.

It seems to me that you want to remove functionality just because you don't
think it's necessary.  I disagree with that.  IMO, functionality should
only be removed if it's a significant maintenance burden.  Why should we
gratuitously make users' lives more difficult?

Jason


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