[PATCH v6 1/1] fortran: Fix arrays of variable length strings for FORTRAN

[Tom Tromey]

>>>>> Abdul Basit Ijaz <abdul.b.ijaz@intel.com> writes:

> From: "Ijaz, Abdul B" <abdul.b.ijaz@intel.com>
> Before this change resolve_dynamic_array_or_string was called for
> all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end,
> this function always called create_array_type_with_stride, which
> creates a TYPE_CODE_ARRAY type.

Thank you for the patch.

> +  else if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_STRING)
> +    {
> +      /* The following special case for TYPE_CODE_STRING should not be
> +	 needed, ideally we would defer resolving the dynamic type of the
> +	 array elements until needed later, and indeed, the resolved type
> +	 of each array element might be different, so attempting to resolve
> +	 the type here makes no sense.
> +
> +	 However, in Fortran, for arrays of strings, each element must be
> +	 the same type, as such, the DWARF for the string length relies on
> +	 the object address of the array itself.
> +
> +	 The problem here is that, when we create value's from the dynamic

The apostrophe should be removed here.

> +	 array type, we resolve the data location, and use that as the
> +	 value address, this completely discards the original value
> +	 address, and it is this original value address that is the
> +	 descriptor for the dynamic array, the very address that the DWARF
> +	 needs us to push in order to resolve the dynamic string length.
> +
> +	 What this means then, is that, given the current state of GDB, if
> +	 we don't resolve the string length now, then we will have lost
> +	 access to the address of the dynamic object descriptor, and so we
> +	 will not be able to resolve the dynamic string later.
> +
> +	 For now then, we handle special case TYPE_CODE_STRING on behalf of
> +	 Fortran, and hope that this doesn't cause problems for anyone
> +	 else.  */

I guess this is due to the approach taken by the Intel compiler.  Is
this true for all Fortran compilers, though?  For example, did you try
this with gfortran?

These DWARF approaches are really unfortunate -- there should be a more
standard way to separate the type's meaning and the type's
representation, especially for "slice" types -- but I guess we're stuck
with it for now.

> +  if (prop != nullptr && type->code () == TYPE_CODE_STRING)
> +    {
> +       prop = nullptr;
> +       warning (_("byte stride property ignored on string type"));
> +    }

I'm sort of meh on this.  Like, there are other warnings from this
function, but on the other hand, this is not something a user can do
anything about.  I guess it serves to say "you're about to see garbage".

thanks,
Tom