RFA: Deprecate C++ options

RFA: Deprecate C++ options

[Nathan Sidwell]

Hi,
There are several flags which change the language compiled by G++.
It's difficult to support any particular combination of them. See
http://gcc.gnu.org/ml/gcc/2001-04/msg01243.html for an example.

I'd like to deprecate and then remove them from g++ asap. I
suggest deprecating them in 3.1 and removal in 3.2

Support of old ARM conformant code
-fno-for-scope
	the for loop variable's scope extends beyond the loop
-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.
-fno-operator-names
	don't have `and' `or' etc as keywords

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

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.

No doubt this is an SC issue, perhaps Mark or Jason could raise it there?

thanks

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: RFA: Deprecate C++ options

[Mark Mitchell]

--On Thursday, September 06, 2001 11:41:37 AM +0100 Nathan Sidwell 
<nathan@codesourcery.com> wrote:

> Hi,
> There are several flags which change the language compiled by G++.
> It's difficult to support any particular combination of them. See
> http://gcc.gnu.org/ml/gcc/2001-04/msg01243.html for an example.
>
> I'd like to deprecate and then remove them from g++ asap. I
> suggest deprecating them in 3.1 and removal in 3.2
>
> Support of old ARM conformant code
> -fno-for-scope
> 	the for loop variable's scope extends beyond the loop
> -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.
> -fno-operator-names
> 	don't have `and' `or' etc as keywords

I agree.  All of these will cause minor headaches for people working
with very old code, but all are easily fixed, and none have been
considered correct C++ for ages, and all would simplify the compiler.
On that basis, -fno-operator-names is the least compelling; supporting
that does not cost much at all.

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

The new parser fixes many of the remaining bugs -- but there's no guarantee 
yet that it will be in 3.1.  In general, the bugs that I know of with the
new parser are a subset of those with the old, and they are of the
flavor where we do not report errors that we should, not vice versa.

So, I agree with deprecating this as well.

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

Agreed.  Any code that depends on this is unbelievably fragile.

> No doubt this is an SC issue, perhaps Mark or Jason could raise it there?

I don't know that removing these switches is an SC issue, but it might
be.  Let's see if we can get developer consensus first.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Tim Hollebeek]

> > I'd like to deprecate and then remove them from g++ asap. I
> > suggest deprecating them in 3.1 and removal in 3.2
> >
> > Support of old ARM conformant code
> > -fno-for-scope
> > 	the for loop variable's scope extends beyond the loop
> > -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.
> > -fno-operator-names
> > 	don't have `and' `or' etc as keywords
> 
> I agree.  All of these will cause minor headaches for people working
> with very old code, but all are easily fixed, and none have been
> considered correct C++ for ages, and all would simplify the compiler.

In the real world, people need to be able to compile old software.  I
propose that the lifetime of -fno-for-scope and friends be mandated to
be no shorter than that of -traditional (conservatively, let's call
that 1-2 decades).  Yes, it is a PITA for compiler developers to support
older language standards.  So be it.  At one point, that code was
considered legal, required for portability to other ARM compliant
compilers, and gcc supported it.

If people would rather combine these options into -lang=c++-arm, to
reduce the number of combinations of options that is possible, then do
that.  But don't succumb to the silly argument that it is no longer
necessary to produce a compiler that knows how to compile this
relatively recent code.  Planned obselescence is a Microsoft strategy,
not a GNU strategy.

-Tim

Re: RFA: Deprecate C++ options

[Joseph S. Myers]

On Thu, 6 Sep 2001, Tim Hollebeek wrote:

> In the real world, people need to be able to compile old software.  I
> propose that the lifetime of -fno-for-scope and friends be mandated to
> be no shorter than that of -traditional (conservatively, let's call
> that 1-2 decades).  Yes, it is a PITA for compiler developers to support

 ... and it's over a decade since C89 was released, somewhat longer than
that since ANSI C drafts were being widely distributed and used, so what
do people think of deprecating -traditional now and removing it in 3.2?  
The rationale from a proposal to remove -traditional I drafted a while ago
is:

-traditional complicates the compiler with code to support
(incompletely) a poorly defined language dialect that has been
obsoleted by a language standard for over a decade (and to a large
extent by widely distributed ANSI C drafts for some time before that).
Because of the use of flag_traditional in dwarf2out.c and dwarfout.c,
other front ends gratuitously need to include definitions of it.
-traditional does not work with the GNU C library, and in general has
become obsolete, not useful (the only times I've actually wanted
pre-ISO C compilation have been for old IOCCC entries, and
-traditional hasn't worked for them) and a maintenance burden because
of additional code to understand and preserve when changing the
compiler, instead of simply following the C standard; I don't know
pre-ISO C so there's no guarantee that such -traditional behaviour
will get correctly preserved.  Previous versions of the compiler
remain available for people wanting -traditional support.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFA: Deprecate C++ options

[Mark Mitchell]

--On Thursday, September 06, 2001 11:21:36 PM +0100 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Thu, 6 Sep 2001, Tim Hollebeek wrote:
>
>> In the real world, people need to be able to compile old software.  I
>> propose that the lifetime of -fno-for-scope and friends be mandated to
>> be no shorter than that of -traditional (conservatively, let's call
>> that 1-2 decades).  Yes, it is a PITA for compiler developers to support
>
>  ... and it's over a decade since C89 was released, somewhat longer than
> that since ANSI C drafts were being widely distributed and used, so what
> do people think of deprecating -traditional now and removing it in 3.2?

I would support this, too -- even though it seems somewhat more
radical.  I agree that I have not found a good use for -traditional
in ages; the code that I have seen that needs pre-ISO stuff uses enough
weird stuff that even -traditional does not support that it still doesn't 
work.

The key point is not that it's not a useful feature -- it's that it's
not useful unless it really works.  Given unlimited resources, I'd
definitely keep it; without them, I'm tempted to focus on the bigger
wins.  It's nearly certain that no GNU software needs this flag; I
wonder if anyone wants to search the Debian package distributions to
see if any of them are built with -traditional?

We would need nearly 100% consensus here to have a shot at getting
this past the SC and the FSF, I suspect.  I am not optimistic.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Zack Weinberg]

On Thu, Sep 06, 2001 at 06:22:48PM -0700, Mark Mitchell wrote:
> 
> I would support this, too -- even though it seems somewhat more
> radical.  I agree that I have not found a good use for -traditional
> in ages; the code that I have seen that needs pre-ISO stuff uses enough
> weird stuff that even -traditional does not support that it still doesn't 
> work.
> 
> The key point is not that it's not a useful feature -- it's that it's
> not useful unless it really works.  Given unlimited resources, I'd
> definitely keep it; without them, I'm tempted to focus on the bigger
> wins.  It's nearly certain that no GNU software needs this flag; I
> wonder if anyone wants to search the Debian package distributions to
> see if any of them are built with -traditional?

As Joe points out, there's a distinction to be made between the
traditional preprocessor and the traditional C compiler.

I can say with confidence that no Debian package in the current
archives uses the traditional C compiler, because that does not 
work at all with glibc >=2.1's headers.  I would support dropping
that code from gcc.

There are plenty of uses for the traditional preprocessor,
e.g. Imake.  It's implemented as a separate program right now, so it
doesn't impose any maintenance burden on cpplib.  We could
theoretically split it into its own package and distribute it
separately, but I don't think that would be worth the trouble.

Here's another proposal, which might sound radical, but I bet it'd
have even less user-visible impact: Let's drop support for every host
and target that doesn't have a C89-compliant standard library.  That
would mean, for instance, we could throw away fix-header and about
two-thirds of fixincludes.

zw

Re: RFA: Deprecate C++ options

[Mark Mitchell]

> As Joe points out, there's a distinction to be made between the
> traditional preprocessor and the traditional C compiler.

Indeed.  Traditional cpp is so engrained in some parts that it
may be around for quite some time.

> I can say with confidence that no Debian package in the current
> archives uses the traditional C compiler, because that does not
> work at all with glibc >=2.1's headers.  I would support dropping
> that code from gcc.

Yes, that sounds like a pretty convincing argument to me.  It's
an option that is never used to build GNU software and cannot be
used on a GNU system...

> Here's another proposal, which might sound radical, but I bet it'd
> have even less user-visible impact: Let's drop support for every host
> and target that doesn't have a C89-compliant standard library.  That
> would mean, for instance, we could throw away fix-header and about
> two-thirds of fixincludes.

I assume that you're exempting embedded targets with no real
standard library at all?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Richard Henderson]

On Thu, Sep 06, 2001 at 09:59:55PM -0700, Mark Mitchell wrote:
> I assume that you're exempting embedded targets with no real
> standard library at all?

Host, not target.


r~

Re: RFA: Deprecate C++ options

[Zack Weinberg]

On Thu, Sep 06, 2001 at 09:59:55PM -0700, Mark Mitchell wrote:
> 
> >Here's another proposal, which might sound radical, but I bet it'd
> >have even less user-visible impact: Let's drop support for every host
> >and target that doesn't have a C89-compliant standard library.  That
> >would mean, for instance, we could throw away fix-header and about
> >two-thirds of fixincludes.
> 
> I assume that you're exempting embedded targets with no real
> standard library at all?

Yep.  I'm speaking only of pre-C89 hosted libraries.  To a first
approximation, the targets I don't like are the ones where fix-header
has to make up header files in order to meet C89 basic requirements.
Think SVR3, BSD4.2, etc.

And yes, I do mean targets.  We're well insulated from pre-C89 host
libraries by libiberty and careful coding.  It's the K+R target
libraries that cause headaches.

zw

Re: RFA: Deprecate C++ options

[Richard Henderson]

On Thu, Sep 06, 2001 at 09:55:05PM -0700, Zack Weinberg wrote:
> I can say with confidence that no Debian package in the current
> archives uses the traditional C compiler, because that does not 
> work at all with glibc >=2.1's headers.  I would support dropping
> that code from gcc.

I would support this as well.

> Here's another proposal, which might sound radical, but I bet it'd
> have even less user-visible impact: Let's drop support for every host
> and target that doesn't have a C89-compliant standard library.  That
> would mean, for instance, we could throw away fix-header and about
> two-thirds of fixincludes.

I suspect this won't fly.  You wouldn't be able to build on, say,
BSD4.3, or any of the other popular retro-computing hosts.


r~

Re: RFA: Deprecate C++ options

[Mark Mitchell]

--On Thursday, September 06, 2001 10:13:58 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Thu, Sep 06, 2001 at 09:55:05PM -0700, Zack Weinberg wrote:
>> I can say with confidence that no Debian package in the current
>> archives uses the traditional C compiler, because that does not
>> work at all with glibc >=2.1's headers.  I would support dropping
>> that code from gcc.
>
> I would support this as well.

I'm thrilled.

Zack, I suggest we wait a week to see if there are serious objections.
If not, I'll raise it with the SC; I don't think we can do this
for the C front end without SC signoff.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Joseph S. Myers]

On Thu, 6 Sep 2001, Mark Mitchell wrote:

[deprecating -traditional]
> Zack, I suggest we wait a week to see if there are serious objections.
> If not, I'll raise it with the SC; I don't think we can do this
> for the C front end without SC signoff.

I don't recall seeing objections; have you now raised this with the SC?
If we get an SC decision in time, the deprecation warning ("-traditional
is deprecated and will be removed in GCC 3.2") when -traditional is passed
to cc1 could go in 3.0.2 as well as 3.1.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFA: Deprecate C++ options

[Mark Mitchell]

--On Tuesday, September 18, 2001 12:42:58 PM +0100 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Thu, 6 Sep 2001, Mark Mitchell wrote:
>
> [deprecating -traditional]
>> Zack, I suggest we wait a week to see if there are serious objections.
>> If not, I'll raise it with the SC; I don't think we can do this
>> for the C front end without SC signoff.
>
> I don't recall seeing objections; have you now raised this with the SC?

No, but thank you for reminding me.  I will do so now.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Zack Weinberg]

On Thu, Sep 06, 2001 at 10:13:58PM -0700, Richard Henderson wrote:
> On Thu, Sep 06, 2001 at 09:55:05PM -0700, Zack Weinberg wrote:
> > Here's another proposal, which might sound radical, but I bet it'd
> > have even less user-visible impact: Let's drop support for every host
> > and target that doesn't have a C89-compliant standard library.  That
> > would mean, for instance, we could throw away fix-header and about
> > two-thirds of fixincludes.
> 
> I suspect this won't fly.  You wouldn't be able to build on, say,
> BSD4.3, or any of the other popular retro-computing hosts.

Can you honestly say that those people are not better off sticking
with 2.x?  We have enough trouble keeping the mainline usable on
modern targets...

zw

Re: RFA: Deprecate C++ options

[Richard Henderson]

On Thu, Sep 06, 2001 at 11:45:47PM -0700, Zack Weinberg wrote:
> Can you honestly say that those people are not better off sticking
> with 2.x?  We have enough trouble keeping the mainline usable on
> modern targets...

I'd be much more likely to be in favour of converting gcc sources
itself to C89.  I.e. do away with PARAMS, remove (int)enum, assume
stdargs, etc.  In that case, one can use gcc 2.x to build gcc 3.x,
and then you're happy.

But if we assume a C89 library, you can _never_ build gcc 3.x on
that old system.  Well, "never" is too strong -- it depends on
whether the missing functionality can be hidden with libiberty.

Moreover, there are fixincludes hacks needed even for supposedly
compliant system headers, so I don't think we'll ever be able to
get rid of that.  At which point I don't think we're gaining much
in the way of maintainence improvement.


r~

Re: RFA: Deprecate C++ options

[Joe Buck]

>  ... and it's over a decade since C89 was released, somewhat longer than
> that since ANSI C drafts were being widely distributed and used, so what
> do people think of deprecating -traditional now and removing it in 3.2?

-traditional is still needed in the C preprocessor and will be essentially
forever, to process non-C code.  But other uses could be deprecated, or
there could even be a separate executable that would do traditional C
preprocessing for use in applications that need it.

Those who want to say "the C preprocessor should not be used to process
text that is not C", save your typing: such use is pretty pervasive.

Re: RFA: Deprecate C++ options

[George Garvey]

On Thu, Sep 06, 2001 at 02:42:57PM -0700, Mark Mitchell wrote:
> > -fno-for-scope
> > -fcheck-new
> > -fno-operator-names
> 
> I agree.  All of these will cause minor headaches for people working
> with very old code, but all are easily fixed, and none have been
> considered correct C++ for ages, and all would simplify the compiler.
> On that basis, -fno-operator-names is the least compelling; supporting
> that does not cost much at all.

Thanks from one of those who will be caused minor headaches (probably
several day's work if you do this and one wants to use a recent compiler)
for working with very old (unmaintained but essential) code (consisting of
thousands of line of now incorrect C++), but all are easily fixed (with
hours of work that will need to be done by every single individual using
the unmaintained code).

Re: RFA: Deprecate C++ options

[Mark Mitchell]

> Thanks from one of those who will be caused minor headaches (probably
> several day's work if you do this and one wants to use a recent compiler)
> for working with very old (unmaintained but essential) code (consisting of
> thousands of line of now incorrect C++), but all are easily fixed (with
> hours of work that will need to be done by every single individual using
> the unmaintained code).

There's no need to be sarcastic.  If you don't like Nathan's proposal,
just say so.

Here's a serious question, not meant to be facetious in any way.  Would
you rather have support for these old constructs, or other improvements
to the compiler, including better support for the lanaguage as specified
in the standard, better optimizations, and (especially) fewer bugs?
(These pre-ISO features take a disproportionate amount of work to
keep working, especially as new features are added, and they tend to
get broken often.)

I think a rational person could answer either way.  What's your
opinion?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Jason Merrill]

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

Re: RFA: Deprecate C++ options

[Nathan Sidwell]

Thanks for all the input on this. [Jason, I thought you were on
holiday - get back to having a break!]

> 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.
Whilst, in general I agree with you, at what point does it become difficult
to support the old semantics? That depends on 'random' future development
directions. For instance, as you know, the implicit typename extension is
going away because of its implementation difficulty and conflict with the
std. Breaking non-conformant code in one go might be better than continual
breakage at each new gcc release.

Bernard Dautrevaux wrote:
> 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
I did mean this - first issue a 'this is deprecated and will be removed'
warning, and then in some later release remove it.

> > -fcheck-new
> 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.
plus what should
	foo = new T ()
call? operator new (size_t) throw (bad_alloc), or operator new (size_t,
no_throw_t const &) throw ()? What should a failing dynamic_cast <T &> (foo)
do? probably some other things I've not realised.

> 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?
Not because they're unnecessary, but because they increase the maintainance
burden. In a conforming C++ world, they are unnecessary. Is it a worthwhile
and acheivable goal to get there? Of the current maintainers Jason has the
longest historical perspective on g++. It was your query about my
recent patch to compound statments and -fno-for-scope that reminded
me to ask about deprecating these things. 

The g++ developer resource is time constrained, we have to prioritize and 
ration it. To paraphrase a floating point saying,
	std conformance, backwards compatibility, bug fixes: Pick *two*

Tim Hollebeek wrote:
> If people would rather combine these options into -lang=c++-arm, to
> reduce the number of combinations of options that is possible, then do
> that.  But don't succumb to the silly argument that it is no longer
> necessary to produce a compiler that knows how to compile this

With a clean slate, this would have been a sensible idea. Implementing
that now would have a number of issues which might make it unrealistic.
1) old code would need its build/configure/make files updating to specify
-lang=c++-arm, rather than -fno-for-scope .... If you have to touch the
package anyway, why not fix the problem properly?
2) I suspect the ARM may be ill-defined in exactly the areas where
traditional c++ differs from std c++.

George Garvey wrote:
> Thanks from one of those who will be caused minor headaches (probably
> several day's work if you do this and one wants to use a recent compiler)
> for working with very old (unmaintained but essential) code (consisting of
> thousands of line of now incorrect C++), but all are easily fixed (with
> hours of work that will need to be done by every single individual using
> the unmaintained code).
Why is a popular, essential package unmaintained? It'll die of bit rot from
more sources than compiler language changes. This is not to denigrate
your minor headaches, but which would you prefer.
a) one headache on one compiler upgrade (with advanced warning in a previous
upgrade that that was going to happen)
b) minor headaches on compiler upgrades when 'oops, we could not keep
backwards compatibility here' happens?

In summary it seems that all developers, bar Jason, would like a std
conformant compiler only (Though Jason's opinion carries a lot of weight)
Users, however, are against the idea or losing backwards compatible
options.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: RFA: Deprecate C++ options

[George Garvey]

On Fri, Sep 07, 2001 at 09:02:43AM -0700, Mark Mitchell wrote:
> There's no need to be sarcastic.  If you don't like Nathan's proposal,
> just say so.

   Its an expression of frustruation. Whether its necessary or not you've
now told me, and I apologize for tastelessly expressing the way I see it.
   What I really object to is one person stating the consequences for
thousands of people unknown to that one, rather than asking. Yes, I know,
Nathan asked.

> Would you rather have support for these old constructs, or other
> improvements to the compiler, including better support for the lanaguage
> as specified in the standard, better optimizations, and (especially)
> fewer bugs?

   I can't answer that, since I've now been informed its an either/or. I
don't know:
      1. The degree of effort required, due to no personal experience on
         this particular subject;
      2. The man-power available; for the same reason.
So I would not trust any decision I made.
   Were this a project I were personally developing; and I came across this
problem; and saw that it could not be done: I would question the design of
the system I was working on.
   I'm not saying its not good, but I'd certainly question it and get the
answer to whether it has an intrinsic design flaw since it can't support
continuing the feature easily. That's is the first impression without
enough hands-on experience with this project to know if its valid.
   Here I'm a user, and I don't have a valid opinion so I won't express
one. But, in bad taste or not, you now have the point of view of one user,
and the consequences of the decision which you (as a group) will make, who
may or may not be representative. That's what I would prefer the developers
do: ask the users, rather than saying they know the consequences for them.
   We are hoping to move away from the unsupported code, but cannot say
when, because it must be replaced, not discarded. Suspect there's quite a
few folk in this position.
   Perhaps you could take this into account when you make an informed
decision, which makes more sense than asking me to make an uninformed
decision. Because, as a user, the answer is I want both.
   The only opinion I can properly express: I would like to have a compiler
that is not so incredibly slow and produces working code. If that requires
removing those features, so be it. I'll take my lumps. I did not hear that.
I heard "its hard" not "its necessary". I suspect it may be necessary due
to problems with the design of gcc, but don't know for sure. If that's
true, I would question continuing that design. I know that's another issue
entirely.
   FYI, we've upgraded a number of computers for developers twice now: once
due to the doubling of memory needs for EGCS (pretty simple and
inexpensive); once for the doubling of compile times for GCC 3 (equally
simple, but not as inexpensive, and less effective). But we bought the
ability to turn off all the defines for EGCS bug work-arounds that were
reported, if there was a response (not always), it was: fixed in 3.
   Truth is, I would have kept the mouth shut if there hadn't been such a
sweeping statement about the effects on people who are unknown to you.
   I hope that answers your question.

Re: RFA: Deprecate C++ options

[Mark Mitchell]

>    Perhaps you could take this into account when you make an informed
> decision, which makes more sense than asking me to make an uninformed
> decision. Because, as a user, the answer is I want both.

Right; I understand that.

Yes, there are some problems with the way that GCC has been implemented
that make these things hard, and there is also some inherent complexity.

>    The only opinion I can properly express: I would like to have a
> compiler that is not so incredibly slow and produces working code.

Right.  I would say my three personal pet peeves, in order, as a C++
user, are correctness, compile times, and robustness in the face of
errors.

   Truth is, I would have kept the mouth shut if there hadn't been such a
> sweeping statement about the effects on people who are unknown to you.

I'm sorry if I offended.  FWIW, I've been a C++ user for nearly as long
as anyone outside of AT&T, and have worked with a lot of real C++
users, so I'm not totally uninformed.

One of the annoyings things to some people is that these extensions to
support old code have been gradually breaking and changing their meaning
from G++ release to G++ release, partly due to their being no clear
definition of their semantics, and partly due to the fact that those
of us working on G++ tend to forget that they're there.

>    I hope that answers your question.

Thanks.  That was very helpful.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFA: Deprecate C++ options

[Gerald Pfeifer]

On Fri, 7 Sep 2001, George Garvey wrote:
>    FYI, we've upgraded a number of computers for developers twice now: once
> due to the doubling of memory needs for EGCS (pretty simple and
> inexpensive); once for the doubling of compile times for GCC 3 (equally
> simple, but not as inexpensive, and less effective).

I believe you'll be very positively surprised when GCC 3.0.2 will be
released (in October) -- compile times *and* code-generation quality are
significantly better for lots of C++ sources than for GCC 3.0 and 3.0.1.

(If it's important, you might want to try a current (CVS) snapshot off
the 3.0-branch.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: RFA: Deprecate C++ options

[George Gargey]

On Wed, Sep 12, 2001 at 03:26:26PM +0200, Gerald Pfeifer wrote:
> On Fri, 7 Sep 2001, George Garvey wrote:
> >    FYI, we've upgraded a number of computers for developers twice now: once
> > due to the doubling of memory needs for EGCS (pretty simple and
> > inexpensive); once for the doubling of compile times for GCC 3 (equally
> > simple, but not as inexpensive, and less effective).
> 
> I believe you'll be very positively surprised when GCC 3.0.2 will be
> released (in October) -- compile times *and* code-generation quality are
> significantly better for lots of C++ sources than for GCC 3.0 and 3.0.1.

   Unfortunately, I didn't follow your instructions precisely, so perhaps
this doesn't count. I used the last snapshot tarball (20010910) instead of
direct from CVS.
   Compiled one of the in-house C++ systems from scratch using 3.0.1 and
the snapshot last night:
	gcc-3.0.1:
		1853.43s user 45.26s system 50% cpu 1:02:46:71 total
	gcc-3.0.1.1 [3.0.2 20010910 (prerelease)]:
		1849.85s user 44.17s system 50% cpu 1:02:37:50 total
   No check for difference in code generation, of course, just compile
times.

Re: RFA: Deprecate C++ options

[Gerald Pfeifer]

On Fri, 14 Sep 2001, George Gargey wrote:
>    Unfortunately, I didn't follow your instructions precisely, so perhaps
> this doesn't count. I used the last snapshot tarball (20010910) instead of
> direct from CVS.
>    Compiled one of the in-house C++ systems from scratch using 3.0.1 and
> the snapshot last night:
> 	gcc-3.0.1:
> 		1853.43s user 45.26s system 50% cpu 1:02:46:71 total
> 	gcc-3.0.1.1 [3.0.2 20010910 (prerelease)]:
> 		1849.85s user 44.17s system 50% cpu 1:02:37:50 total
>    No check for difference in code generation, of course, just compile
> times.

This is fine, as basically the situation was like that for (some) C++
code:

  GCC 3.0:   slow code generation    slow code generated
  GCC 3.0.1: faster code generation  somewhat slower code generated
  GCC 3.0.2: faster code generation  faster code generated

So, when comparing 3.0.1 with 3.0.2(prerelease), you should see about
the some compilation time, but better performance for your binaries.

GCC 3.0.2 should be strictly better than 3.0 in *both* areas.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: RFA: Deprecate C++ options

[Benjamin Kosnik]

> I'd be much more likely to be in favor of converting gcc sources
> itself to C89.  I.e. do away with PARAMS, remove (int)enum, assume
> stdargs, etc.  In that case, one can use gcc 2.x to build gcc 3.x, and
> then you're happy.

May I live to see the day.

> Moreover, there are fixincludes hacks needed even for supposedly
> compliant system headers, so I don't think we'll ever be able to get
> rid of that.  At which point I don't think we're gaining much in the
> way of maintenance improvement.

Right. This is tilting at windmills: some kind of fixincludes is going
to be necessary regardless of C89/C99 conformance. (Note we need
fixincludes anyway, because some vendor headers have incorrect with
respect to C99 bits.)

> > -fno-for-scope
> > -fcheck-new
> > -fno-operator-names

I vote for these to go as well. My general position, I reiterate, is
for a standards-conformant compiler by default. I think kidding
ourselves that flags to change the C++ ABI are necessary or even
useful is a delusional mistake.

-benjamin

Re: RFA: Deprecate C++ options

[Benjamin Kosnik]

> Right.  I would say my three personal pet peeves, in order, as a C++
> user, are correctness, compile times, and robustness in the face of
> errors.

So then. 

I'm assuming correctness is being taken care of with the parser rewrite? 

Compile times can/could be taken care of with a combination of some of
the inlining work plus pre compiled headers. 

I think it might be wise to establish a target for a release that
incorporates some of these more far-reaching solutions.

-benjamin

Re: RFA: Deprecate C++ options

[Mark Mitchell]

--On Friday, September 07, 2001 10:13:15 AM -0700 Benjamin Kosnik 
<bkoz@redhat.com> wrote:

>
>> Right.  I would say my three personal pet peeves, in order, as a C++
>> user, are correctness, compile times, and robustness in the face of
>> errors.
>
> So then.
>
> I'm assuming correctness is being taken care of with the parser rewrite?

Some/much correctness issues, yes.  But, lots of front-end things
(builtin operator overloading rules, template instantiation trickiness,
etc.) are not.  And, of course, back end bugs are part of correctness
too.

> Compile times can/could be taken care of with a combination of some of
> the inlining work plus pre compiled headers.

Those are partial solutions, but they may be good enough.

> I think it might be wise to establish a target for a release that
> incorporates some of these more far-reaching solutions.

Yes -- but it's too early to do so yet.  It's too early to even be
sure we can get the new parser done before October 15th, which is the
cut off for major new features in GCC 3.1.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

RE: RFA: Deprecate C++ options

[Bernard Dautrevaux]

Hi,

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


> -----Original Message-----
> From: Jason Merrill [ mailto:jason_merrill@redhat.com ]
> Sent: Friday, September 07, 2001 10:29 PM
> To: Nathan Sidwell
> Cc: gcc@gcc.gnu.org; mark@codesourcery.com
> Subject: 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.
> 

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.

Agreed

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


Agreed,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
--------------------------------------------