From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39275 invoked by alias); 5 Apr 2016 10:47:05 -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 39262 invoked by uid 89); 5 Apr 2016 10:47:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:209.85.220.66, Hx-spam-relays-external:209.85.220.66, HX-Received:10.67.7.37 X-HELO: mail-pa0-f66.google.com Received: from mail-pa0-f66.google.com (HELO mail-pa0-f66.google.com) (209.85.220.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 05 Apr 2016 10:46:54 +0000 Received: by mail-pa0-f66.google.com with SMTP id hb4so968148pac.1 for ; Tue, 05 Apr 2016 03:46:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=cMbYypJQaKfLmQzaAdtHFjEKoe6hJ5FNtjxHb0dxE5k=; b=MoB+SjhKRfU9J+WRuJ0Uop6lUtuUCVqKlWcKR6mYOxrbXhFyXPCelcWH/l6khfpZlU iBm+5MX6gvV4oosou3V/PCXL3HM04ReHpIY8ltQLLbnWFq+O3zYg8t1j/RQpHS3dj4lS 0mGLn5rF2JMG6AmBLAHZb9s4NnepFgr2YL0I6eocuCPQ9diJKVD6jbSRHHqspz+/lnFe ovwAiwSUQJHGP5RudRzUeSdyHiM/ddJqm+UHOQsRDXmeKO8KEaOJj+LX4HdjtaWciXDL EGtJVCmjiubcQox8pL77CyaSmno7YaSdpsXGtnfFBmtcJN0BXn83r67UEgU5uKlU4BZ4 /+sQ== X-Gm-Message-State: AD7BkJLPbpAL+y5PAg9spsja2zzY9ezEt9T29SW/OVoYUWaLq+cbw9zazVocEB3bRqFbhg== X-Received: by 10.67.7.37 with SMTP id cz5mr14912216pad.18.1459853213144; Tue, 05 Apr 2016 03:46:53 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id o69sm45894138pfi.14.2016.04.05.03.46.49 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 05 Apr 2016 03:46:52 -0700 (PDT) From: Yao Qi To: "Heckel\, Bernhard" Cc: Yao Qi , brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] fort_dyn_array: Enable dynamic member types inside a structure. References: <1458204189-13267-1-git-send-email-bernhard.heckel@intel.com> <1458204189-13267-2-git-send-email-bernhard.heckel@intel.com> <86h9fhpkkz.fsf@gmail.com> <570369BC.60407@intel.com> Date: Tue, 05 Apr 2016 10:47:00 -0000 In-Reply-To: <570369BC.60407@intel.com> (Bernhard Heckel's message of "Tue, 5 Apr 2016 09:31:08 +0200") Message-ID: <86inzwnxik.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00066.txt.bz2 "Heckel, Bernhard" writes: > Actually, when resolving dynamic types I don't use the valaddr. From > what I understood > I could even return if valaddr is not Null as the TYPE should already > be resolved at that time. > But I was unsure about it and kept the code. OK, that is a separate issue. >> >>> pinfo.next =3D addr_stack; >>> TYPE_FIELD_TYPE (resolved_type, i) >>> @@ -2090,8 +2091,13 @@ resolve_dynamic_struct (struct type *type, >>> resolved_type_bit_length =3D new_bit_length; >>> } >>> - TYPE_LENGTH (resolved_type) >>> - =3D (resolved_type_bit_length + TARGET_CHAR_BIT - 1) / TARGET_CHAR= _BIT; >>> + /* Type length won't change for fortran. Keep what we got from DWARF. >> Two spaces after ".". Multiple instances of this problem. >> >>> + Dynamic fields might change over time but not the struct definiti= on. >>> + If we would adapt it we run into problems when >>> + calculating the element offset for arrays of structs. */ >> What is the problem we run into? > Imagine we have a dynamic allocatable array as a member of a > structure. The size of the dynamic array can vary over time. > When we have resolved this allocatable array we don't want to add it's > length to the structure length it belongs to. > Dynamic members are not embedded in the structure itself. Only the > description of the dynamic type is embedded > and the size of the description (address, bounds,...) won't change. That is a FORTRAN specific feature. The structure's size changes when the dynamic array's size changes in C. I am not 100% sure about Ada, but I suspect it is the same as C in this aspect after I read https://sourceware.org/ml/gdb-patches/2014-05/msg00522.html Could you rewrite the comments to say the length of type won't change for FORTRAN, but the length changes for C (and Ada?). >>> -=0C >>> /* Access to the value history. */ >>> /* Record a new value in the value history. >>> @@ -2416,6 +2428,12 @@ set_internalvar (struct internalvar *var, struct= value *val) >>> call error () until new_data is installed into the var->u to avoid >>> leaking memory. */ >>> release_value (new_data.value); >>> + >>> + /* Internal variables which are created from values with a dynam= ic location >>> + don't need the location property of the origin anymore. >>> + Remove the location property in case it exist. */ >>> + remove_dyn_prop(DYN_PROP_DATA_LOCATION, value_type(new_data.valu= e)); >> Space is needed before "(". What is wrong if we don't do so? Do you >> have a test case for this? > An internal variable has it's own valaddr to where the copy is located. > If we keep the dynamic location from the origin then this > dyn. location will be used to set > the value component location. > As the internal variable is a copy of an value at a certain point in > time I prefer to get rid off the > dynamic location attribute then to do some "if else if else" > constructs when setting the component location. We remove the dynamic properties from type A for internal variable, but there is another variable is still using type A. These dynamic properties can't be found any more. Is it a problem? > There are tests: > gdb.fortran/vla-value.exp: print $myvar set to vla1 > gdb.fortran/vla-value.exp: print $myvar(3,6,9) but they are PASS in mainline. --=20 Yao (=E9=BD=90=E5=B0=A7)