This is the mail archive of the
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Aug 2002 08:53:45 -0600
- Subject: Re: C++ ABI Issues
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Mark Mitchell
>Certainly, one reasonable position is to do nothing. Another is to
>(as several have suggested) support both modes (which seems like
>a good idea to me). Another is my initial suggestion (to fix the
>problems right away.) To me, the best argument for my suggestion is
>that at this point there aren't too many people dependent on 3.2; the
>longer we leave it around the harder it may to be change it later.
Believe me I understand your point.
Unfortunately, Red Hat is far enough along in it's cycle that revving the
compiler again isn't really feasible. So for Red Hat at least, GCC 3.2 is
the compiler for the next major release of Red Hat Linux and for any
follow-on minor releases.
>Your point, made previous by Joe, that we are likely to find more bugs,
>is also a very good one.
Yes, which is why I think it's so important that we build our our testing
infrastructure so that next time we say "we've implemented the multi-vendor
ABI and we're going to be compatible going forward" that we actually have
some confidence in that statement.
If that means that we don't rev the ABI for GCC 3.3, but instead wait for
GCC 3.4, then, well, so be it. That would actually be an improvement in
a lot of ways as we've never had major releases without an ABI change.
>I recently had discussions with folks at HP about what to do when these
>things come up. They've got an almost-compliant compiler deployed in
>the field; so do we. They're very interested in being compatible with
>GCC. Nobody wants to break things for their users. It's a difficult
>situation, and the discussions didn't reach an easy solution -- although
>everyone was very clear that the ultimate goal is to keep from messing
>up things for users. I'd love it if we had a process in place to deal
>with these issues when they arise.
Not at all unlike the discussions I've had with Intel. We're all trying to
get to the same place -- the problem is that we're not all going to get there
at the same time. Though sharing of testcode, results and the like between
the interested parties will be a significant step in the right direction.