Re: [V4 01/18] vla: introduce allocated/associated flags

[Keven Boell <keven dot boell at linux dot intel dot com>]

On 09.02.2015 07:52, Joel Brobecker wrote:
> [Copying Doug, as I think Doug has experience in this area, and is
> also dealing with the kind of giant programs where size of types
> really make a big difference]
> 
>> Fortran 90 provide types whose values may be dynamically
>> allocated or associated with a variable under explicit
>> program control. The purpose of this commit is to read
>> allocated/associated DWARF tags and store them to the
>> main_type.
>>
>> 2014-05-28  Keven Boell  <keven.boell@intel.com>
>>             Sanimir Agovic  <sanimir.agovic@intel.com>
>>
>> 	* dwarf2read.c (set_die_type): Add reading of
>> 	allocated/associated flags.
>> 	* gdbtypes.h (struct main_type): Add allocated/
>> 	associated dwarf2_prop attributes.
>> 	(TYPE_ALLOCATED_PROP): New macro.
>> 	(TYPE_ASSOCIATED_PROP): New macro.
>> 	(TYPE_NOT_ALLOCATED): New macro.
>> 	(TYPE_NOT_ASSOCIATED): New macro.
> 
> struct main_type is size-critical, so we simply cannot add
> fields to it that only a very small minority of instances
> will actually be using..
> 
> To avoid the size increase, I propose that we turn...
> 
>   struct dynamic_prop *data_location;
> 
> ... into a chained list of dynamic properties. To determine
> which type of property each element in the list is, we'll need
> to introduce an enumerated type to be used as discriminant.
> 
> So, I propose something like that:
> 
> /* FIXME: Add comment.  */
> 
> enum dynamic_prop_kind
> {
>   /* FIXME: Document.  */
>   DYNAMIC_PROP_DATA_LOCATION,
>   /* FIXME: Document.  */
>   DYNAMIC_PROP_ALLOCATED,
>   /* FIXME: Document.  */
>   DYNAMIC_PROP_ASSOCIATED,
> };
> 
> /* FIXME: Document.  */
> 
> struct dynamic_prop_list
> {
>   enum dynamic_prop_kind kind;
>   struct dynamic_prop *prop;
>   struct dynamic_prop_list *next;
> };
> 
> ... then replace...
> 
>   struct dynamic_prop *data_location;
> 
> ... into ...
> 
>   struct dynamic_prop_list *dyn_prop_list;
> 
> ... and finally adjust the macros to go through the list instead of
> accessing the data through the dedicated fields. Using a function
> which does the search for a given kind will probably be useful.
> 
> I think you might find it easier to do it in 2 stages (and therefore
> two patches):
> 
>   1. Convert the current "data_location" field to the list scheme;
>   2. Then add the two new kinds of properties, which should then
>      be fairly straightforward.
> 

Hi Joel,

Thanks for your reply. Appreciate the time you invested for reviewing the patches.
I will re-work this part to have the new attributes as a linked list as you proposed and will come up with an updated patch series.

Thanks,
Keven