This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: dje at watson dot ibm dot com (David Edelsohn), davem at redhat dot com (David S. Miller), mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Tue, 27 Aug 2002 12:56:01 -0600
- Subject: Re: C++ ABI Issues
- Reply-to: law at redhat dot com
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