This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ ABI Issues


In message <200208271708.KAA26617@atrus.synopsys.com>, Joe Buck writes:
 >David Edelsohn writes:
 >
 >> 	As was discussed during the GCC 3.2 transition, my personal
 >> opinion is that GCC needs a binary -fabi-correctly switch which defaults
 >> to *OFF*.  We maintain the GCC 3.2 ABI until a well-defined transition
 >> point in the future when the switch is changed to default to *ON*.
 >
 >I would be satisfied with this approach, though we could probably come up
 >with a better choice of option names.  After all, we can never be certain
 >that we are correct.  All we can do is have two modes: 3.2 compatibility,
 >and 3.2 plus any ABI corrections found to date.
 >
 >Maybe the flag should be -fabi-gcc-3.2 .  If true, we are compatible with
 >GCC 3.2; if false, we include as many bug fixes as we have to ABI conformance
 >at the time.  It would be true by default until we have reasonable
 >confidence that we've converged, and I think we need six months to achieve
 >such confidence, assuming that we do some rigorous testing in that time.
Agreed.

 >To have a reasonable chance of catching nearly all the ABI bugs, we're
 >probably going to need at least six months.  What this will mean, assuming
 >that Red Hat 8, Debian, FreeBSD, and SuSE all adopt 3.2 is that 3.2 will
 >be a de-facto standard ABI.  The effect of this can be minimized if we
 >provide warnings at points where there is a known error in 3.2's ABI
 >conformance and encourage distributors to avoid such coding in any C++
 >libraries
I've recommended this internally and externally.  It's one of the reasons
why I believe every time we find a bug in our ABI implementation we should
add a warning to the compiler so folks can find out if their code triggers
the ABI bug.

I've already recommended internally that as these issues are found that
we should push a new rev of the compiler to our Red Hat Linux customers
ASAP to make sure compilers with the warnings are as widely available as
possible.

 > (if a "hit" does occur, it's easy to make it go away by adding a
 >dummy field that fills in the empty space in the base class's padding).
 >If this can be done, then an eventual switch to a compiler that does
 >correct ABI will not cause compatibility problems, because code that could
 >trigger compatibility problems would be avoided.
Even better!


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]