Re: RFA: Deprecate C++ options

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

GCC 3.1 and branches (was: RFA: Deprecate C++ options)

[Gerald Pfeifer]

On Sun, 9 Sep 2001, Mark Mitchell wrote:
> 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.

Given the increasingly higher number of branches, I'm starting to get
worried about this deadline.


First, I'm not sure all developers are aware of it. (Well, after your
and my message they problably are. <g>)

And second, I'm afraid that around that date, we will see lots of merges
with destabilizing effects.

Not in the sense that GCC doesn't build any longer or has additional
testsuite failures (this should be prevented by the merge guidelines), but
in the form of compile-time regressions, code-quality regressions, and
problems on more uncommon platforms, all of which will be very hard to
track down after a multitude of huge merges.

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

Re: GCC 3.1 and branches (was: RFA: Deprecate C++ options)

[Mark Mitchell]

> Not in the sense that GCC doesn't build any longer or has additional
> testsuite failures (this should be prevented by the merge guidelines), but
> in the form of compile-time regressions, code-quality regressions, and
> problems on more uncommon platforms, all of which will be very hard to
> track down after a multitude of huge merges.

That's why there are 4 months on the schedule between the mergepoint
and the branch, and two months on the schedule between the branch
and the release.  There will be time to fix the problems, and
the people who commit from the branches should be responsive to any
such problems.

Of course, people should not rush to check things in just because
there is a deadline.  If they're not ready, they're not ready.

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

Re: GCC 3.1 and branches (was: RFA: Deprecate C++ options)

[Gerald Pfeifer]

On Thu, 13 Sep 2001, Mark Mitchell wrote:
> That's why there are 4 months on the schedule between the mergepoint
> and the branch, and two months on the schedule between the branch
> and the release.  There will be time to fix the problems [...]

Yes, of course.  What I meant was that if we have lots of commits from
several branches within an extremely short period (a few days before the
deadline), it will be extremely hard to analyse regressions of the kind I
mentioned, because it won't be easy to see which of the multiple mergers
might be responsible.

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

Re: GCC 3.1 and branches (was: RFA: Deprecate C++ options)

[Mark Mitchell]

--On Friday, September 14, 2001 02:34:34 PM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> On Thu, 13 Sep 2001, Mark Mitchell wrote:
>> That's why there are 4 months on the schedule between the mergepoint
>> and the branch, and two months on the schedule between the branch
>> and the release.  There will be time to fix the problems [...]
>
> Yes, of course.  What I meant was that if we have lots of commits from
> several branches within an extremely short period (a few days before the
> deadline), it will be extremely hard to analyse regressions of the kind I
> mentioned, because it won't be easy to see which of the multiple mergers
> might be responsible.

True.  TO that end, it would be nice if people would not push everything
up against the deadline.  But, realistically, they will -- heck, I
may do it myself with the new parser! -- so I bet there will be some
chaos for a week or two around that point.  I think we'll be able to
sort it out.

Thanks,

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