From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55871 invoked by alias); 2 Sep 2016 13:44:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55861 invoked by uid 89); 2 Sep 2016 13:44:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=claimed, H*r:sk:orsmga1, row, H*RU:HELO X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Sep 2016 13:44:20 +0000 Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 02 Sep 2016 06:44:18 -0700 X-ExtLoop1: 1 Received: from heckel-mobl3.ger.corp.intel.com (HELO [172.28.205.46]) ([172.28.205.46]) by FMSMGA003.fm.intel.com with ESMTP; 02 Sep 2016 06:44:16 -0700 Subject: Re: [V4 00/21] Fortran dynamic array support To: Jan Kratochvil References: <88072818E0A3D742B2B1AF16BBEC65A7263E6F2E@IRSMSX107.ger.corp.intel.com> <20160715091352.GA8059@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263E8FD9@IRSMSX107.ger.corp.intel.com> <20160716151310.GA14331@host1.jankratochvil.net> <20160716151837.GA797@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com> <20160816135920.GA26624@host1.jankratochvil.net> <57B6D831.4080605@intel.com> <20160821170346.GA21909@host1.jankratochvil.net> <57BC50D1.4020102@intel.com> <20160825170626.GA29717@host1.jankratochvil.net> Cc: "Weinmann, Christoph T" , gdb-patches@sourceware.org From: Bernhard Heckel Message-ID: <57C9822F.1020800@intel.com> Date: Fri, 02 Sep 2016 13:44:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160825170626.GA29717@host1.jankratochvil.net> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00040.txt.bz2 On 25/08/2016 19:06, Jan Kratochvil wrote: > On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote: >> created a branch with all stride patches. > users/bheckel/fortran-strides > 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b > >> I don't see regression on RH7.1, gcc 4.8.3-9 > I see a regression for 32-bit targets (x86_64-m32 or native i686) > on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64). I do not see the regres= sion > on CentOS-7.2 (x86_64-m32). > > print pvla^M > value requires 4294967288 bytes, which is more than max-value-size^M > (gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element > > I have attached a fix. > > It is because: > <115> DW_AT_lower_bound : 4 byte block: 97 23 10 6 (DW_OP_p= ush_object_address; DW_OP_plus_uconst: 16; DW_OP_deref) > <11a> DW_AT_upper_bound : 4 byte block: 97 23 14 6 (DW_OP_p= ush_object_address; DW_OP_plus_uconst: 20; DW_OP_deref) > <11f> DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e (DW_OP_p= ush_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_m= ul) > DW_AT_lower_bound =3D=3D 1 > DW_AT_upper_bound =3D=3D 1 > DW_AT_byte_stride =3D=3D (-2) * 4 =3D=3D -8 > > I am not sure if gfortran is really wrong or not but a stride does not ma= ke > sense for me for a single row array. > > Attaching also gdb.fortran/vla-stride.f90 from your branch built with > gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode. > > Besides that I see on all archs > -FAIL: gdb.pascal/arrays.exp: Print dynamic array of string > +FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB interna= l error) > but that testcase is only in Fedora and the Pascal (fpc) support has been= not > well maintained so far so I am OK with that. > > > Thanks, > Jan Hi Jan, found the root cause of the issue on 32bit inferior. According to DWARF4 (Page 100) strides can be negative but evaluation of=20 dynamic properties in GDB is done via CORE_ADDR which is unsigned. This causes the issue that the type length seems to be way to big. The following code is not claimed to be a fix, just want to point you to=20 the right direction. In gdbtypes.c: prop =3D &TYPE_RANGE_DATA (dyn_range_type)->stride; if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value)) { /* if target is 32bit, execute next if clause */ if (value > (2^31)) value +=3D 2^32; stride.kind =3D PROP_CONST; stride.data.const_val =3D value; } Also, in dwarf2read.c all DW_AT_...STRIDE 's are handles as unsigned.=20 This has to be fixed as well. I will investigate more on the stride topic next week. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928