This is the mail archive of the
mailing list for the GCC project.
ABI compliance should be default for gcc 3.4
- From: "Moore, David" <david dot moore at intel dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Wed, 15 Oct 2003 16:52:22 -0700
- Subject: ABI compliance should be default for gcc 3.4
Gcc 3.4 contains a lot of fixes for? C++? ABI bugs? found in gcc 3.2. There is an option to select either gcc 3.2 compatibility or C++ ABI compliance.??C++ ABI compliance should be the default
For C++ compatibility and interoperability, ?the vast majority of the community will choose the default. Making?C++ ABI?compliance the default will mean gcc 3.4? compiled binaries?will not be binary compatible with gcc 3.2? compiled binaries. It?would, however, be the right decision at this point.?
The C++ ABI was developed with strong influence from gcc developers and has been carefully thought out to be consistent with the C++ standard. At least one of the bugs in gcc 3.2 is not C++ standard compliant and is in fact fairly ugly; gcc 3.2 will sometimes position an empty base class at an offset that is beyond the limits of the structure "containing" it. There may be others.
We have already seen an example of the problems that can arise trying to emulate bugs from an earlier version with gcc 3.3, where one bug fix inadvertently changed the layout of structures in a corner case. So already gcc 3.3 is not totally compatible with gcc 3.2. This could get worse in the future. gcc 3.2 C++ ABI bugs might also have an effect on the LSB. Perhaps some of them could get cemented into that standard. This is certainly something that should be avoided.
Standards compliance has great?value for the community?and now??that gcc 3.4 is C++ ABI compliant,??that should be the default. Linux?usage is growing rapidly, so putting off changing the default to?be?C++ ABI compliant only makes it harder to achieve later. C++ ?ABI bug fixes are important enough that taking the backwards compatibility hit between gcc 3.2 and gcc 3.4 is worthwhile.??To?do otherwise locks these bugs into gcc and that would be detrimental to gcc and to Linux in general.