[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 15 Sep 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |aldyh at gcc dot gnu.org,
>                    |                            |rguenth at gcc dot gnu.org
> 
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I'm afraid this is similar to the DW_AT_string_length troubles (but not to the
> direct reference to a DIE of some local variable, which can be besides the hack
> we have now solved using DWARF extension, but to the indirect one where we only
> have the hack which won't really work for LTO).
> 
> In this case, when the FE fills in the array_descr_info, it fills in:
> (gdb) p debug_generic_stmt (info->dimen[0].lower_bound)
> *(D#1 + 32);
> 
> $4 = void
> (gdb) p debug_generic_stmt (info->dimen[0].upper_bound)
> *(D#1 + 40);
> 
> $5 = void
> (gdb) p debug_generic_stmt (info->dimen[0].stride)
> *(D#1 + 24) * span.0;
> 
> The first two are representable just fine,
>         .uleb128 0x4    # DW_AT_lower_bound
>         .byte   0x97    # DW_OP_push_object_address
>         .byte   0x23    # DW_OP_plus_uconst
>         .uleb128 0x20
>         .byte   0x6     # DW_OP_deref
> and
>         .uleb128 0x4    # DW_AT_upper_bound
>         .byte   0x97    # DW_OP_push_object_address
>         .byte   0x23    # DW_OP_plus_uconst
>         .uleb128 0x28
>         .byte   0x6     # DW_OP_deref
> but the problem is with the stride, it refers to a local variable, but
> obviously during early debug we don't really have location description for that
> variable.  And like for DW_AT_string_lenght, DW_OP_call{2,4,_ref} isn't the
> 100% answer here, because those expect the referenced DIE has DWARF expression
> rather than location description.  So we'd need DW_OP_variable_value or
> something similar.

So DW_OP_GNU_implicit_ptr doesn't work here?  Not sure
I understand how DW_OP_GNU_implicit_ptr works fully.  That is,

  ... *(D#1 + 24)
  DW_OP_GNU_implicit_ptr <span.0> + 0
  DW_OP_mul

the examples in the specification always finish the dwarf expression
with DW_OP_GNU_implicit_ptr which wouldn't be the case here.