Re: GCC 3.3, GCC 3.4

[Mark Mitchell <mark@codesourcery.com>]

--On Thursday, January 30, 2003 12:29:10 PM -0600 Benjamin Kosnik 
<bkoz@redhat.com> wrote:

>
> I think your proposed schedule is highly unrealistic.

Feel free to suggest a better one!  (I like it when things like this
happen; a lot of times starting to move one way gets people excited
and they show us a better way to go.)

> 1) Some kind of planned ABI breakage. When? How is it tested? Putting
> this off to the last minute might be ok for the compiler, but I no
> longer think this is acceptable, in practice, for the C++ runtime.
> Versioning the runtime is non-trivial.

I do not think this is not an issue for 3.3; no ABI breakage is supposed
to occur there as far as I know.

I don't think that's been decided for 3.4 yet, but I think it's great
that you're bring it up.  What do you think?

On the compiler side, I don't think there's much point in changing the
ABI until we can get 100% compliant.  (The ways in which we're wrong
don't really affect users, and the fewer times we change the better.)

At this point, I believe our vtable, VTT, and object layout situation
is extremely good.  In other words, I know of no bugs, and I've looked
very hard using lots of eyes and lots and lots of tests.  (Thousands.)

I do know of name-mangling bugs, and my work on the mainline over the
past few days is designed to work towards solving these problems.  We
need fully correct dependent name analysis in order to get this right,
and that's work in the front end.

> 2) Any kind of ABI testing. I don't think the Intel ABI tester is
> sufficient.

This is a hard problem and one I'm very familar with.

This is a problem we have had since forever with G++, and it is better
than it has been.

There's more I'd like to say, but I can't.  Hopefully soon.

If you have suggestions, I'm sure they'd be very welcome!

> 3) Any kind of attempt at compile-time regressions or compile time
> performance at all. Dropping the release criteria, or ignoring the
> release criteria that deals with compile time performance is unacceptable.
> Sane defaults in the garbage collector would be a big win here.

Well, Mike just checked in a patch that provides a 33% speedup.  On the
head, I've checked in several patches that improve performance by several
percent, and have more in the works.  Nathan is working on a patch to
remove exponential (no, not just quadratic, exponential) behavior in the
C++ front end that has been there since *forever* -- probably 2.7.2.

My job as RM is to help with patches on the branch; I'll try to review
patches if you send them to me personally.

> 4) Deficiencies in the testing plan. For gcc-3.0.0, Peter Schmidt did a
> wonderful job of keeping the rest of the developers in the know about
> how key software packages were performing when compiled with the
> soon-to-be-released compiler. A return to actually testing the software
> packages that are in the release criteria, and not shipping until they
> pass, would be welcome.

Would you please volunteer to run the tests and extract PRs for GNATs?

That would be a huge help since it would allow people to focus on
whatever bugs have been introduced.

Also, would you send me a phone number where you can be reached?  I'd
like to talk to you for a few minutes, if you're available.

Thanks,

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