From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4530 invoked by alias); 15 Jan 2003 21:51:22 -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 4521 invoked from network); 15 Jan 2003 21:51:20 -0000 Received: from unknown (HELO black-watch.firstnet.net.uk) (212.103.224.244) by sources.redhat.com with SMTP; 15 Jan 2003 21:51:20 -0000 Received: (qmail 15122 invoked from network); 15 Jan 2003 21:51:35 -0000 Received: from unknown (HELO scgj.streamline) (212.103.239.121) by 0 with SMTP; 15 Jan 2003 21:51:35 -0000 Received: from elmo.streamline (scpe.streamline [192.168.1.66]) by scgj.streamline (8.9.3/8.6.9) with ESMTP id VAA11722 for ; Wed, 15 Jan 2003 21:51:16 GMT Received: (from david@localhost) by elmo.streamline (8.11.6/8.11.6) id h0FLp4018006 for gdb-patches@sources.redhat.com; Wed, 15 Jan 2003 21:51:04 GMT Date: Wed, 15 Jan 2003 21:51:00 -0000 From: David Lecomber To: gdb-patches@sources.redhat.com Subject: Fortran: Intel vs G77 Message-ID: <20030115215104.A17981@streamline-computing.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-SW-Source: 2003-01/txt/msg00583.txt.bz2 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 838 The current situation with g77 and Intel meets gdb is as follows for multi-dim arrays Intel compiled code: whatis -- wrong way round real(4 * 5 ) is reported as real (5 * 4) indexing -- correct print elements -- boundaries not aligned properly ( it prints a 5 * 4 as a 4 * 5 ) g77 fortran compilers compiled code: whatis -- correct print elements -- correct indexing -- 'print A(1,2)' will get the wrong answer. So, unless there is a method to check what the compiler was used, we are left with 1. status quo or 2. compile up two different versions -- one for gdb + intel, the other for gdb + g77 Does anyone know of the existence of such a check? Patches to fix the three issues are attached, but of course they cannot all be applied at once; the fix to make g77 work will bust intel, and vice-versa.. David --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.g77-array-printing-patch" Content-length: 621 *** eval.c Fri Jan 4 17:51:38 2002 --- eval.c Wed Oct 16 14:08:04 2002 *************** evaluate_subexp_standard (struct type *e *** 1358,1364 **** if (retcode == BOUND_FETCH_ERROR) error ("Cannot obtain dynamic lower bound"); ! array_size_array[i] = upper - lower + 1; /* Zero-normalize subscripts so that offsetting will work. */ --- 1358,1364 ---- if (retcode == BOUND_FETCH_ERROR) error ("Cannot obtain dynamic lower bound"); ! array_size_array[nargs - i + 1] = upper - lower + 1; /* Zero-normalize subscripts so that offsetting will work. */ --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.intel-print-elements-patch" Content-length: 1665 *** f-valprint.c Mon Oct 21 17:47:36 2002 --- /tmp/gdb-5.2/gdb/f-valprint.c Mon Oct 21 16:14:33 2002 *************** f77_create_arrayprint_offset_tbl (struct *** 234,239 **** --- 234,241 ---- int eltlen; int ndimen = 1; int upper, lower, retcode; + int i, j; + int t; tmp_type = type; *************** f77_create_arrayprint_offset_tbl (struct *** 256,270 **** ndimen++; } /* Now we multiply eltlen by all the offsets, so that later we can print out array elements correctly. Up till now we know an offset to apply to get the item but we also have to know how much to add to get to the next item */ ndimen--; eltlen = TYPE_LENGTH (tmp_type); F77_DIM_OFFSET (ndimen) = eltlen; ! while (--ndimen > 0) { eltlen *= F77_DIM_SIZE (ndimen + 1); F77_DIM_OFFSET (ndimen) = eltlen; --- 258,285 ---- ndimen++; } + /* Now we multiply eltlen by all the offsets, so that later we can print out array elements correctly. Up till now we know an offset to apply to get the item but we also have to know how much to add to get to the next item */ ndimen--; + + /** + intel compiler, reckon this to be wrong way round.. so here's a quick in-place swap. + */ + + for (i = 1, j = ndimen; i < j; i++,j--) { + t = F77_DIM_SIZE(i); + F77_DIM_SIZE(i) = F77_DIM_SIZE(j); + F77_DIM_SIZE(j) = t; + } + eltlen = TYPE_LENGTH (tmp_type); F77_DIM_OFFSET (ndimen) = eltlen; ! ! while (--ndimen > 0) { eltlen *= F77_DIM_SIZE (ndimen + 1); F77_DIM_OFFSET (ndimen) = eltlen; --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gdb.intel-print-whatis-patch" Content-length: 1526 *** f-typeprint.c Sun Jan 20 19:42:04 2002 --- f-typeprint.c Mon Oct 21 16:18:12 2002 *************** f_type_print_varspec_suffix (struct type *** 175,183 **** if (arrayprint_recurse_level == 1) fprintf_filtered (stream, "("); - if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_ARRAY) - f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0); retcode = f77_get_dynamic_lowerbound (type, &lower_bound); --- 175,183 ---- if (arrayprint_recurse_level == 1) fprintf_filtered (stream, "("); + else + fprintf_filtered (stream, ","); retcode = f77_get_dynamic_lowerbound (type, &lower_bound); *************** f_type_print_varspec_suffix (struct type *** 212,221 **** if (TYPE_CODE (TYPE_TARGET_TYPE (type)) != TYPE_CODE_ARRAY) f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0); if (arrayprint_recurse_level == 1) fprintf_filtered (stream, ")"); - else - fprintf_filtered (stream, ","); arrayprint_recurse_level--; break; --- 212,223 ---- if (TYPE_CODE (TYPE_TARGET_TYPE (type)) != TYPE_CODE_ARRAY) f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0); + + if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_ARRAY) + f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0); + if (arrayprint_recurse_level == 1) fprintf_filtered (stream, ")"); arrayprint_recurse_level--; break; --3MwIy2ne0vdjdPXF--