From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22876 invoked by alias); 5 Oct 2009 10:08:23 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 22866 invoked by uid 22791); 5 Oct 2009 10:08:22 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Subject: Re: Patch for pascal-dynamic arrays From: Joost van der Sluis To: Project Archer In-Reply-To: <20091004141705.GA18527@host0.dyn.jankratochvil.net> References: <1252939529.28930.33.camel@wsjoost.cnoc.lan> <20090916154453.GA23913@host0.dyn.jankratochvil.net> <1254326374.2755.14.camel@wsjoost.cnoc.lan> <20091004141705.GA18527@host0.dyn.jankratochvil.net> Content-Type: text/plain Date: Mon, 05 Oct 2009 10:08:00 -0000 Message-Id: <1254737294.3257.21.camel@wsjoost.cnoc.lan> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Language-Detected: en X-Spam-Scanned: InterNLnet Mail Scan System V2.03 X-SW-Source: 2009-q4/txt/msg00001.txt.bz2 On Sun, 2009-10-04 at 16:17 +0200, Jan Kratochvil wrote: > On Wed, 30 Sep 2009 17:59:34 +0200, Joost van der Sluis wrote: > > Attached it the new patch. > > Please write GNU style ChangeLog entry for it. I am sorry I did not write the > entries myself in the log (as a partial excuse it was not reviewed by anyone > that time). > > > > I tested it and I have no regressions anymore. > > Getting a lot of regressions included below. I had no Fortran installed. > * Some fortran failures only happen with `ulimit -v 500000'. > * Are the new Pascal testcase FAILures expected? If a more recent fpc is > required the testcase should XFAIL, not FAIL. Yes, they need a new fpc-version (2.3.1 or higher). > > @@ -197,6 +198,13 @@ struct value > > /* If value is a variable, is it initialized or not. */ > > int initialized; > > > > + CORE_ADDR data_address; > > + > > + char calc_length; > > + long length; > > + char checked_dynamics; > > + long lower_bound; > > + long upper_bound; > > > Still I do not like duplicating the information already present in `struct > main_type'. I find right you have changed passing some `struct type *' to > `struct value *' instead but that new `struct value' just could use > copy_type_recursive on that linked `struct type'. I didn't thought about that. In principle, that information should be removed from 'struct main_type', since the lower_bound, upper_bound and length aren't defined for plain structures, without any address set. But that would be far to intrusive. But I wanted to do it as 'clean' as possible, that's why the duplication. I'll look if I can fix it without the duplication as you suggested. Thanks for looking at it, Joost