Re: C++ ABI Issues

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

> | The compiler can warn that gcc 3.2 and a compiler that implements the ABI
> | document correctly will lay out a class differently.  But given this
> | knowledge, how is it supposed to figure out what the user wants to happen?
> | It doesn't know which compiler compiled the "other half" of the code: the
> | library being called, or the caller of the library.

> Aren't we talking of a bug in GCC -- which other compilers known to
> implement the ABI don't have?

It's a bug in GCC, yes.  Given the presence of that bug, what should a C++
software developer do?  He or she has no choice but to use padding.

> | You appear to assume that these padding objects will be needed all over
> | the place.
> 
> No.  I'm not comfortable with using warts and code uglification to try
> to do the compiler's work.  We do know the bugs we're talking about.

Do you intend to implement time travel and go back and fix GCC 3.2?  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?  You appear to be focussed only on fixing C++ libraries we
ship (libstdc++).  Let's say you're putting together the Debian "sarge"
release and you have to ship 800 or so packages containing C++ code
(remember, their package count recently passed 10,000).  Your job is to
assure that all of that code comes out the same on gcc 3.2 as on a fixed
gcc 3.4, because if you don't, you'll have another painful episode where
every binary C++-containing package has to be replaced when someone
upgrades the compiler.  How do you do it?

My answer is that you use Mark's warning patch, find all the code that
triggers warnings, and add pads until the warning goes away.  Your answer
appears to be, um, what?  Punt, saying that you're not comfortable with
code uglification?  It doesn't appear that you have a solution that will
allow for 3.2 compatibility.

In any case, I suggest postponing further debate until we encounter some
real examples of "violations" in user code and get a handle on how common
they are.  If they are extremely rare, "uglification" will be minimal.
If they are common, then you may be right and we'll need to think of
something else.