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]
Other format: [Raw text]

Re: GCC 3.3, GCC 3.4

>Feel free to suggest a better one!

Perhaps updating this would help this discussion:

Shipping GCC 3.3.0 on March 1 will require enormous effort. 

I guess I'm more concerned about the timing on the gcc-3.4.0 effort.
>From the above link, I cannot tell when it's supposed to be released.

Anyway. I guess I'm just really leery of releases a la 3.1.0. That
release was pushed back into the summer, when students are out of
school, people are on vacation, etc. 

It would seem to me that gcc-3.4, optimally, should be starting to enter
phase three around October. That's after Europe is back from break, and
students around the world are back on it.

Just a thought.

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

Well, me too. However, I expected the SC to show more leadership on this
issue. I'm disappointed by the current lack of policy. Matt had brought
up this issue when the quick, "oops" 3.2.0 release was made. Now I
see the wisdom of his comments.

I've versioned the runtimes assuming that 3.3 will not break the 3.2
ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
this was an ok decision.

I'd prefer a better process though.

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

Sounds good. I'd prefer to not break the runtime ABI unless I knew wide
io worked. That effort is just starting. There are issues with the
current runtime ABI, that can be gleaned from the versioning patches of
last week.

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

I don't see how.

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

This continues to annoy me, but I understand why you do it. The longer
you say this line, the less I believe there's anything to say.

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

My suggestion: somebody develop a GPL'd, FSF copyright (negotiable) ABI
testsuite. Both EDG and Codesourcery have them, the rest of us should too.

I continue to believe that proprietary testsuites are just as evil as
proprietary compilers and runtimes.

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

Sorry, but no. I don't have the time to do this well. I think that Janis
(and the rest of the regression hunters, bangerth in particular) are
really doing a good job along these lines for mainline: they should be
encouraged to continue efforts on the release branch.

I think the longer gcc, as a project, goes on without an autobuild
continuous regression checker, the worse off things will get. It was
nice of Red Hat to initially support this effort, but it is obvious that
this time is past as the regression checker is long dead. Somebody else
will have to step up with the bandwidth, time, and machine to do this.

Some of these frustrations are with the development process, and have
nothing to do with you or the SC. Please keep in mind that I have the
utmost respect for both you and the SC.


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