From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14899 invoked by alias); 17 Jan 2004 12:07:23 -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 14892 invoked from network); 17 Jan 2004 12:07:22 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 17 Jan 2004 12:07:22 -0000 Received: from gnat.com (hoosic.gnat.com [205.232.38.102]) by nile.gnat.com (Postfix) with ESMTP id 8C0D6F2D9F; Sat, 17 Jan 2004 07:07:22 -0500 (EST) Message-ID: <4009257C.6080204@gnat.com> Date: Sat, 17 Jan 2004 12:07:00 -0000 From: Robert Dewar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: law@redhat.com Cc: Richard Kenner , dnovillo@redhat.com, gcc@gcc.gnu.org Subject: Re: [RFC] Contributing tree-ssa to mainline References: <200401170610.i0H6AEBX027059@speedy.slc.redhat.com> In-Reply-To: <200401170610.i0H6AEBX027059@speedy.slc.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01040.txt.bz2 law@redhat.com wrote: > In message <10401170230.AA15232@vlsi1.ultra.nyu.edu>, Richard Kenner writes: > Given the lack of movement on that front, how can we realistically expect > any movement on something like tree-ssa? Particularly when tree-ssa > depends on function at a time mode? > > Given the lack of movement from the Ada maintainers on that front, can we > realistically consider the Ada front-end even maintained, except perhaps > in a bugfix mode? Well in practice there is a huge amount of development on the Ada front end, probably as much or more than any other gcc front end. It is really a question of priorities. We don't have any Ada users for whom function at a time is an important issue, where as there are a heap of other important and urgent enhancements. So that tends to make function at a time non-urgent, even if of course important in the long run. Even in the area of performance, for Ada users concerned with code quality, the important issues are not in general optimization of the back end, but rather Ada specific issues (e.g. efficient handling of multi-dimensional packed arrays). I agree with Richard, it is not that serious a problem if there is a lag and Ada is unavailable for a while. That unavailability would in fact obviously create an increased urgency for getting function at a time to work for Ada. After all, for years, GNAT users were successfully using GCC 2.8 and it took quite a long time to get GNAT working with GCC 3. We are now over that bump, and no doubt function at a time will be achieved relatively soon. We can't commit a definite schedule (since projects urgently needed by (and funded by) our customers will take priority and can preempt non-funded projects, but that does not mean that the non-funded projects don't eventually get done. If the arguments for including tree-ssa are strong enough, my viewpoint would be that there is no need to let Ada be a blocking issue.