From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9539 invoked by alias); 31 Aug 2004 00:48:40 -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 9530 invoked from network); 31 Aug 2004 00:48:39 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 31 Aug 2004 00:48:39 -0000 Received: (qmail 11394 invoked from network); 31 Aug 2004 00:48:38 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 31 Aug 2004 00:48:38 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Mon, 30 Aug 2004 17:48:37 -0700 To: Robert Dewar Cc: Richard Henderson , Laurent GUERBY , Florian Weimer , gcc@gcc.gnu.org Subject: Re: Ada policy References: <10408301022.AA24170@vlsi1.ultra.nyu.edu> <1093863754.17130.27.camel@pc.site> <20040830090622.GD30497@sunsite.ms.mff.cuni.cz> <1093888894.17130.45.camel@pc.site> <87zn4czaql.fsf@deneb.enyo.de> <1093896230.17130.95.camel@pc.site> <87657074by.fsf@codesourcery.com> <20040830205702.GB2566@redhat.com> <4133A3D2.80202@gnat.com> From: Zack Weinberg Date: Tue, 31 Aug 2004 01:13:00 -0000 In-Reply-To: <4133A3D2.80202@gnat.com> (Robert Dewar's message of "Mon, 30 Aug 2004 18:01:54 -0400") Message-ID: <87brgs5dzu.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01557.txt.bz2 Robert Dewar writes: > Reading Zack's message: >> Second, the Ada maintainers have said in the past that they >> deliberately break source compatibility between releases (such that >> GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)). > > That's entirely wrong. Nothing is broken deliberately, and no one > ever said anything of the kind. I disagree; that *is*, in fact, what is said or at least strongly implied by messages like : # Right now, we are in a transitioning phase, since there is no GCC # release yet with Ada support. We could even disable Ada by default, # as there will be people building binary versions anyway. For future # versions, there is a very clear base compiler that should be used, # which is the previous FSF released version of GCC. Note that that was in the context of a discussion of whether configure should refuse to enable Ada if the "wrong" bootstrap compiler was found. More explicitly, - which you wrote - says that #> It would be nice if we could preserve bootstrap compatibility #> farther back, but if there are major gains to maintainability from #> raising the bar, fine. # # Well certainly we are not going to make incompatibilities for the # sake of making incompatibilties. But there are always cases in every # release where we preserve some kludge for maintainability. and goes on to talk about how it'd be nice to use pragma Unreferenced, but this breaks compatibility with the Ada compiler in GCC 3.[12]. And, grepping gcc/ada, I see that there are now many uses of pragma Unreferenced - so building GNAT with GCC 3.(<3) has indeed been deliberately broken. Now, I say >> There must be guaranteed bidirectional source compatibility between >> all 3.x branches of GCC, such that it is possible to build any 3.x >> version of GNAT with any other 3.x version of GNAT. and I do still insist on that. But that doesn't mean you can't use pragma Unreferenced; it just has to be properly conditionalized so that GCC 3.(<3) somehow sees pragma Warnings (Off) instead. With regard to this statement > Unfortunately there are occasionally cases where bugs cannot be > fixed without breaking this requirement. It's relatively rare, and > for some time now, GNAT has been able to be built with a pretty > significant variety of starting compilers I have some sympathy for a situation where version X of GNAT contained invalid code which version Y (Y > X) correctly rejects; but when this occurs while version X is a still-live release branch, patches should go into version X to correct the bug. When it's a case of version X contains a bug which causes it to miscompile the code in version Y (again, Y > X) I have *no* sympathy. We work around this kind of thing all the damn time in the parts of the compiler that are written in C, and I see no reason why the Ada parts should be any different. I'd also add that personally, I consider my third requirement (patch submission according to the same requirements binding on all other contributors) to be much more important than the one you chose to discuss. zw