Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik <bkoz at redhat dot com>]

> But I'm not sure this really addresses the main problem.  A test
> suite will make sure there aren't any accidental ABI changes.  But
> has that actually been a problem? 

It is my contention that this is a real problem that is currently an
active issue for the gcc-3_2-branch.

There does not seem to be consensus about this. I'm looking for
clarification. If gcc-3.3 and gcc-3.2 are going to diverge right at the
onset, a series of versioning bits will also have to be modified to make
the difference explicit.

I am of the opinion that gcc-3.2 and gcc-3.3 should strive for the same
ABI. If, at some point before gcc-3.3 is released, yet after 3.2 is
released, it is broken, well then. I consider that a different issue.

So, in summary, I'm getting at:

1) I would think that gcc-3.2 and gcc-3.3 should match C++ ABI's at the
point where gcc-3.2 is released. I don't believe they do, but may be
wrong. I'm looking for some help in testing.

2) Ff the released gcc-3.3 will match the released gcc-3.2's ABI is a
decision that can be put off until the gcc-3.3 release process kicks
into gear. In any case, it is a decision that should be explicitly made,
and backed up with some kind of testing.

> Seems to me that the real
> 3.1/3.2 issue is intentional ABI changes: fixing ABI-related bugs in
> 3.1.  The question is whether we'll find more bugs in 3.2, and make
> intentional changes to fix them for 3.3.

It seems likely that more ABI bugs will be encountered after 3.2 is
released. I don't say that lightly, and know how hard everybody is
working on this issue. 

Changing the ABI yet again must be planned. If it doesn't have to be
done, cool. If so, then every developer will know when/what is possible.

> Preventing intentional ABI changes is less a technical issue than
> a management decision.  Look at how Sun has maintained a
> stable C++ ABI, for example.  Mostly it's because they made two
> decisions, and made a commitment to stick to them:

There are two, distinct issues. One: can I verify that a given change,
or two different compilers, have the same ABI? If not, can I see where
they diverge?

There is no testing plan in place.

After this is known, not guessed at, then the second issue is as you
described: when is the ABI broken, and what is the longer term plan.

I think resolving the first issue is of major important at the moment.

-benjamin