This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Joe Buck <Joe dot Buck at synopsys dot com>
- To: gdr at integrable-solutions dot net (Gabriel Dos Reis)
- Cc: Joe dot Buck at synopsys dot COM (Joe Buck), phil at jaj dot com (Phil Edwards),mark at codesourcery dot com (Mark Mitchell), gcc at gcc dot gnu dot org
- Date: Tue, 27 Aug 2002 15:21:13 -0700 (PDT)
- Subject: Re: C++ ABI Issues
Gaby writes:
> Well, if the compiler were to be issueing a warning about a class
> being laid out differently according to ABI differences, then it
> certainly should be possible to tell the nature of the difference and
> how things change from one set to the other. That means, the compiler
> should be able to do the adjustment.
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.
Of course the compiler can and will do the adjustment if it implements
-fabi-gcc-3.2 or whatever we call it. But if the code being called is
compiled by Intel, it had better *not* do the adjustment. Again: how can
it "know"?
> Now, why should we really uglify the class definition? According to
> your statement, it is because we wanted the library to accomodate the
> compiler deficiencies.
Rather, *if* a warning appears, *and* it is important to the developer of
the code that gcc 3.2 and Intel's compiler and a future, fixed gcc will
agree on the layout of some class, then the only safe thing to do is to
design the class in such a way that the warning goes away. Library
versioning won't suffice, and in any case is much more difficult to do
than simply adjusting the class layout.
As I said, it appears that libstdc++ is unaffected. C++ implementations
of CORBA should be looked at, as they are likely to use multiple
inheritance.
You appear to assume that these padding objects will be needed all over
the place. In practice, I expect the need for them to be extremely rare,
because even to use virtual base classes is rare (I despise the things
myself: they violate encapsulation severely unless the virtual base has no
data members, since the most-derived class always has to explicitly
construct the virtual base. And if there are no members, then the ABI bug
does not arise).