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

["Ijaz, Abdul B" <abdul.b.ijaz@intel.com>]

Hi Tom,

Thanks for the feedback.

>> +	 The problem here is that, when we create value's from the dynamic

Tom > The apostrophe should be removed here.

Will fix in V7.

Tom > 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?

I have tested it with ifort/ifx/gfortran. As per DWARF for VLA strings should be encoded like this for all Fortran compiler. After this change GDB  works fine with ifort/ifx. But in case of gfortran it fails though vla-string itself is also encoded using TYPE_CODE_STRING  but there only issue is unexpectedly string is passed as reference to the structure so gdb is not able to handle. I have created following gcc Bugzilla  issue sometime back and XFAIL is used for gfortran in the vla-array.exp newly added test. 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826

Tom > 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".

This was added on feedback so just to handle it and notify, given how closely related arrays and strings seem to be. 

Thanks & Best Regards
Abdul Basit

-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Thursday, January 11, 2024 7:03 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
Cc: gdb-patches@sourceware.org; aburgess@redhat.com
Subject: Re: [PATCH v6 1/1] fortran: Fix arrays of variable length strings for FORTRAN

>>>>> 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
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928