Re: C++ ABI Issues

[Joe Buck <Joe dot Buck at synopsys dot com>]

> | Do you intend to implement time travel and go back and fix GCC 3.2?
> 
> I assume that isn't a question that asks for a sensical answer, right?

I was trying to point out that you are missing the point.  I am puzzled as
to why this is so, but I'm convinced of it.

> |  If
> | not, what advice do you want to give to users, who might need both
> | compilers, or gcc 3.2 plus future, fixed gcc's, to work and to talk to
> | each other?
> 
> The future fixed GCC is where there is a possible divergence from
> GCC-3.2.  That future GCC ought to know about the fix -- since it will
> lay out differently compared to GCC-3.2. That future GCC-3.2 can add the
> missing bits if necessary.

That will not suffice.

The divergence with GCC-3.2 already exists: Intel is shipping a compiler.
What we do in a future GCC is IRRELEVANT.  Anyone developing C++ code that
wants to ship a library on GNU/Linux, who wants people to be able to use
that library for a long time, with a choice of compilers (gcc 3.2, future
gcc's, as well as gcc competitors) has only one choice: avoid the problem.
How, pray tell, can any patch we make to the already-shipped gcc 3.2 make
it match the already-shipped Intel compiler?

Furthermore, if we do as you say and make the future GCC 3.2 "add the
missing bits", just what bits do you intend to add?  Padding?  That will
make it match the GCC 3.2 ABI.  But what if the code being linked to was
built by Intel?  What if the code being linked to will be built with
GCC 3.5?

What has not shipped yet is a production distribution based on GCC 3.2.
This means that the only thing we have an opportunity to change is the
C++ code that is to be compiled.  We cannot implement time travel and
change the compilers.

> | You appear to be focussed only on fixing C++ libraries we
> | ship (libstdc++). 
> 
> As you certainly read in my previous messages, I'm certainly worrying
> about libraries and programs other than libstdc++.

OK.  Perhaps I'm clueless and so are people like Jeff Law, who liked my
suggestion.  Please explain your "add the missing bits" proposal and how
it addresses the requirement of achieving unified and stable ABIs for C++
libraries on GNU/Linux, for users of gcc 3.2, of other compilers that
(attempt to) implement the standard ABI, and for users of future gcc's,
without forcing gcc to be bug-compatible with gcc 3.2 forever.