From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29337 invoked by alias); 8 Jul 2002 15:29:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29291 invoked from network); 8 Jul 2002 15:29:49 -0000 Received: from unknown (HELO echotech.ca) (142.177.255.73) by sources.redhat.com with SMTP; 8 Jul 2002 15:29:49 -0000 Received: (qmail 28723 invoked by uid 0); 8 Jul 2002 15:50:00 -0000 Received: from ben@echotech.ca by capella with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.24173 secs); 08 Jul 2002 15:50:00 -0000 Received: from unknown (HELO amanda) (10.0.0.254) by mailer.echotech.ca with SMTP; 8 Jul 2002 15:50:00 -0000 Content-Type: text/plain; charset="us-ascii" From: Ben Woodhead To: gcc@gcc.gnu.org Subject: Re: C++ binary compatibility between GCC 3.1 and GCC 3.2? Date: Mon, 08 Jul 2002 10:09:00 -0000 User-Agent: KMail/1.4.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200207081230.36009.ben@echotech.ca> X-SW-Source: 2002-07/txt/msg00354.txt.bz2 Hello everybody..=20 If I remember correctly I believe that: gcc x.y.z is=20 x. Major - Architecture Changes,=20 y. Minor - Features added but no major architecture changes (slight changes= to=20 the abi could be possible here, if there are a small number of cases were i= t=20 would affect).=20 z. Patch - Patch levels are for overflows, nothing on the outside changes b= ut=20 possible bugs, such as not testing values, or overflows or fence post error= s. With that out of the way I find it really hard to see an abi change going i= nto=20 a patch level. Please, please please don't do that, 3.1.whatever should all= =20 match.. When talking about the version i should not have to say 3.1.1 becau= se=20 it should have only fixed segfaults and things like that, so the output and= =20 input should be the same, so 3.1 is fine..=20 As far as if this version is closer to version 3.1 or 3.2.. 3.2 does not ex= ist=20 so it can be what ever i want it to be.. ie, you could patch a text file in= =20 3.1 and call it 3.2 and theres nothing anybody can say about it.=20 Just a possible suggestion, release 3.1.1 now the way it is, (on its releas= e=20 date) so the people using 3.1 can get the fixes they need. Then apply the a= bi=20 changes, and test the output, try to find all the abi inconsistencies.. The= n=20 in August release version 3.1.1 with abi changes included as 3.2.=20 That way you don't have to worry about applying a patch a week way from th= e=20 release date or making incompatabilities with 3.1.x. Also on the same not y= ou=20 don't have to try to release 3.2 with all the new features that are not wel= l=20 tested.. Everybodies is happy, the abi changes are in, and you don't have t= o=20 worry about the experamental stuff from 3.2.=20 Thanks,=20 Ben Woodhead Gabriel Dos Reis wrote: > | Well, we could could make a sub-branch from the 3.1 branch for the > | amended ABI, and call it 3.1bis . >=20 > Isn't that going to make some confusion? (That isn't meant to be > rhetorical, that is a serious question) Well, it should generate less confusion than calling it 3.2.x or 3.1.x, since it is clear that it is closer to 3.1 than to 3.2, but not the original 3.1 . It's the second attempt to have a workable 3.1 . =20=20=20=20=20=20=20=20 --=20 -------------------------- SuperH 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ T:+44 1454 462330