From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9046 invoked by alias); 15 Jun 2009 20:38:59 -0000 Received: (qmail 9035 invoked by uid 22791); 15 Jun 2009 20:38:59 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailout11.t-online.de (HELO mailout11.t-online.de) (194.25.134.85) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Jun 2009 20:38:52 +0000 Received: from fwd05.aul.t-online.de by mailout11.t-online.de with smtp id 1MGIx4-0003rz-00; Mon, 15 Jun 2009 22:38:46 +0200 Received: from [192.168.178.27] (ZkizJQZpQhTE4vudSmBn5JvyRMhGzRk+H8GdZ-P9j7P4hHaova516bgHvDQFDlYQfR@[84.156.225.68]) by fwd05.aul.t-online.de with esmtp id 1MGIwg-1i8sS00; Mon, 15 Jun 2009 22:38:22 +0200 Subject: Re: [gnat] reuse of ASTs already constructed From: oliver.kellogg@t-online.de (Oliver Kellogg) Reply-To: okellogg@users.sourceforge.net To: report@gnat.com Cc: gcc@gcc.gnu.org In-Reply-To: <4A05E2CF.6010708@adacore.com> References: <1239557374.7565.37.camel@tidbit.site> <1240083309.4554.45.camel@tidbit.site> <1240175954.4554.50.camel@tidbit.site> <1241385654.4763.38.camel@tidbit.site> <49FE09D9.4090702@adacore.com> <1241386066.4763.42.camel@tidbit.site> <49FE415A.5050601@adacore.com> <1241415395.21122.14.camel@tidbit.site> <1241899436.5909.14.camel@tidbit.site> <4A05E2CF.6010708@adacore.com> Content-Type: text/plain Date: Mon, 15 Jun 2009 20:38:00 -0000 Message-Id: <1245098731.6782.21.camel@tidbit.site> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00324.txt.bz2 A further problem that I'm seeing is that Lib.Writ.Write_Unit_Information assumes the current unit to depend on all entries in Lib.Units. However, when letting Lib.Units accumulate units across several compilations this dependency does not necessarily hold true. The generated ALI files for compilation 2 to N contain more entries than needed. --Oliver On Sat, 2009-05-09 at 16:08 -0400, Robert Dewar wrote: > Oliver Kellogg wrote: > > On 2009-05-04, at 07:36 +0200, Oliver Kellogg wrote: > >> Robert Dewar wrote: > >>>>>>> How about not doing the name expansion in-place but rather > >>>>>>> storing the expanded name in an extra node field? > >>> You could have a separate vector for expanded names I suppose ... > >> So be it. I will change the code to not overwrite the Name field > >> with the expanded name but rather store the expanded name in a > >> data structure separate from the Node. > >> > > > > Luckily, this change was limited to the Exp_Dbug package body. > > FYI I am appending the diff. > > The new Q_E_Name array holds the Name_Id for the expanded name > > of a given entity. The implementation as a fixed array is > > preliminary and I would appreciate suggestions on a better > > data structure to use. > > use a table .. we never use fixed length arrays in the compiler