ABI compliance should be default for gcc 3.4

[Moore, David]

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.
  
 
Comments?
 
David Moore
Intel Corp.