Re: [PATCH 1/3] fort_dyn_array: Enable dynamic member types inside a structure.

[Yao Qi <qiyaoltc@gmail.com>]

"Heckel, Bernhard" <bernhard.heckel@intel.com> 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 = addr_stack;
>>>           TYPE_FIELD_TYPE (resolved_type, i)
>>> @@ -2090,8 +2091,13 @@ resolve_dynamic_struct (struct type *type,
>>>   	resolved_type_bit_length = new_bit_length;
>>>       }
>>>   -  TYPE_LENGTH (resolved_type)
>>> -    = (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 definition.
>>> +     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?).

>>>   -\f
>>>   /* 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 dynamic 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.value));
>> 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.

-- 
Yao (齐尧)