From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29231 invoked by alias); 15 Jan 2003 21:32:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29217 invoked from network); 15 Jan 2003 21:32:56 -0000 Received: from unknown (HELO d9000.firstnet.net.uk) (212.103.224.245) by sources.redhat.com with SMTP; 15 Jan 2003 21:32:56 -0000 Received: (qmail 18755 invoked from network); 15 Jan 2003 21:35:23 -0000 Received: from unknown (HELO scgj.streamline) (212.103.239.121) by 0 with SMTP; 15 Jan 2003 21:35:23 -0000 Received: from elmo.streamline (scpe.streamline [192.168.1.66]) by scgj.streamline (8.9.3/8.6.9) with ESMTP id VAA11706 for ; Wed, 15 Jan 2003 21:32:52 GMT Received: (from david@localhost) by elmo.streamline (8.11.6/8.11.6) id h0FLWeG17977 for gdb-patches@sources.redhat.com; Wed, 15 Jan 2003 21:32:40 GMT Date: Wed, 15 Jan 2003 21:32:00 -0000 From: David Lecomber To: gdb-patches@sources.redhat.com Subject: Patches to improve Fortran support Message-ID: <20030115213240.A17967@streamline-computing.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-SW-Source: 2003-01/txt/msg00582.txt.bz2 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 416 I have attached one of the wrong patch files to my email of Jan 13. The first attached patch only cured the tendency of gdb to allocate -ve large amounts of memory, which was my first attempt at curing the fortran array problem. That was more curing the symptom than the cause, and doesn't work fully anyway.. The new attachment is the fix to the source of the problem. Apologies for the confusion. Cheers David --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.array-ptr-patch" Content-length: 1291 *** ../../TMP/gdb-5.3/gdb/eval.c Sun Dec 15 22:29:59 2002 --- eval.c Sun Dec 15 22:28:41 2002 *************** evaluate_subexp_standard (struct type *e *** 1383,1392 **** offset_item = array_size_array[i] * offset_item + subscript_array[i]; - /* Construct a value node with the value of the offset */ - - arg2 = value_from_longest (builtin_type_f_integer, offset_item); - /* Let us now play a dirty trick: we will take arg1 which is a value node pointing to the topmost level of the multidimensional array-set and pretend --- 1383,1388 ---- *************** evaluate_subexp_standard (struct type *e *** 1395,1401 **** returns the correct type value */ VALUE_TYPE (arg1) = tmp_type; ! return value_ind (value_add (value_coerce_array (arg1), arg2)); } case BINOP_LOGICAL_AND: --- 1391,1405 ---- returns the correct type value */ VALUE_TYPE (arg1) = tmp_type; ! ! f77_get_dynamic_lowerbound (tmp_type, &lower); ! ! /* Construct a value node with the value of the offset */ ! /* lower will get subtracted off in value_subscript, hence add it here */ ! ! arg2 = value_from_longest (builtin_type_f_integer, offset_item + lower); ! ! return value_subscript(arg1, arg2); } case BINOP_LOGICAL_AND: --EVF5PPMfhYS0aIcm--