This is the mail archive of the 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


I just get in the thread today, and want to add some points.

> -----Original Message-----
> From: Jason Merrill []
> Sent: Friday, September 07, 2001 10:29 PM
> To: Nathan Sidwell
> Cc:;
> Subject: Re: RFA: Deprecate C++ options
> >>>>> "Nathan" == Nathan Sidwell <> 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.

I think we must first warn the users that old for scope will soon no more be
supported, then (in 3.2?) change that to an error (with explicit mention of
the fact it *was* an no more supported feature). In a later release (say
3.5) we can then simplify the error message if we think it's no more needed.

> > -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.

I 200% agree. When running in no-exception mode, if users want to be able to
handle out-of-memory errors contextually the only way to work is
-fcheck-new. And that is especially of all those, like me, that use C++ in
embedde real-time contexts, where out-of-memory is a event that must be
taken care of, but where exceptions may not yet be usable.

> > -fno-operator-names
> > 	don't have `and' `or' etc as keywords
> This seems harmless; I don't see any need to remove it.

Me neither, although I've never used them :-)

> > 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.

Don't see any interest in suppressing just the option; either the
optimisation is always needed (and I don't know why it should be) and even
-O0 should do it, either it can be suppressed and -O0 may suppress it but a
specific option would be nice alse (especially if -O0 still does this if
deemed innocent enough)

> 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?



Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85

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