RFA: Deprecate C++ options
Jason Merrill
jason_merrill@redhat.com
Fri Sep 7 13:40:00 GMT 2001
>>>>> "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
More information about the Gcc
mailing list