From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8592 invoked by alias); 12 Apr 2010 19:51:18 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 8583 invoked by uid 22791); 12 Apr 2010 19:51:17 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Mon, 12 Apr 2010 19:51:00 -0000 From: Jan Kratochvil To: Joost van der Sluis Cc: Project Archer Subject: Re: Patch for pascal-dynamic arrays Message-ID: <20100412195106.GA32767@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> <1256751286.31305.24.camel@wsjoost.cnoc.lan> <20091030094726.GA29758@host0.dyn.jankratochvil.net> <1257630529.27675.26.camel@wsjoost.cnoc.lan> <1271071502.27845.15.camel@wsjoost.cnoc.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271071502.27845.15.camel@wsjoost.cnoc.lan> User-Agent: Mutt/1.5.20 (2009-08-17) X-SW-Source: 2010-q2/txt/msg00009.txt.bz2 On Mon, 12 Apr 2010 13:25:02 +0200, Joost van der Sluis wrote: > I have a new patch now that doesn't cause any regressions on my system, on Fedora 12 for x86_64-m32 and native i386 (but not for x86_64 native 64bit): -PASS: gdb.base/store.exp: var struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}} +FAIL: gdb.base/store.exp: var struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}} -PASS: gdb.base/store.exp: up struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}} +FAIL: gdb.base/store.exp: up struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}} Therefore if you have x86_64 native system reproducible by: cd gdb/testsuite; make site.exp; runtest --target_board unix/-m32 gdb.base/store.exp > Any comments, improvements, suggestions? I have to admit I do not fell so comfortable with the part: @@ -1045,8 +1045,8 @@ get_array_bounds (struct type *type, long *low_bound, long *high_bound) if (TYPE_CODE (index) == TYPE_CODE_RANGE) { - low = TYPE_LOW_BOUND (index); - high = TYPE_HIGH_BOUND (index); + low = value_lower_bound (type); + high = value_upper_bound (type); } as it converts the state pre-check_typedef-ed evaluation to a dynamic one. Going to try some alternative adjustment of this part. Thanks, Jan