https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128234
Bug ID: 128234
Summary: gfortran generates DWARF variables suffixed with ".0"
in OpenMP region
Product: gcc
Version: 16.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: josh.cottingham at linaro dot org
Target Milestone: ---
ompiled the above with the following:
> gfortran -g -Og -fopenmp -o openmp-repro ./openmp-repro.f90
This was observed to occur with gfortran 16.1 and 13.3 on x86_64-linux-gnu.
It appears that DWARF generated by gfortran, we see variables which are used in
an OpenMP region are being given names with an extra `.0` suffix. More
specifically, this appears to occur when we have an array of an
"Assumed-shape".
For example, in the above code we can see the following in the DWARF:
> <4><c3>: Abbrev Number: 10 (DW_TAG_variable)
> <c4> DW_AT_name : (indirect string, offset: 0x2ac): array_1.0
> <c8> DW_AT_type : <0x40a>
> <cc> DW_AT_artificial : 1
> <cc> DW_AT_location : 0x67 (location list)
> <d0> DW_AT_GNU_locviews: 0x5f
I assume that this is coming from internal compiler-generated pointers that
exist within the OpenMP region. If we were to try to inspect these variables in
GDB would fail with the following:
> Thread 15 "openmprepro" hit Breakpoint 1,
> populate_elements::populate_elements.0._omp_fn.0 () at ./openmp-repro.f90:20
> 20 array_1 ( iV ) = iV + 10
> (gdb) info locals
> iv = 11
> array_1.0 = 0x7fffffffd330
> ubound.0 = 100
> array_2.0 = 0x7fffffffd010
> iv = -540209920
> (gdb) print array_1.0
> A syntax error in expression, near `.0'.
It is worth noting that on this thread the original array is also not
accessible in GDB:
> (gdb) p array_1
> No frame is currently executing in block openmprepro::populate_elements.
This is likely because the existence of `.0` does not match Fortran naming
conventions (https://gcc.gnu.org/onlinedocs/gfortran/Naming-conventions.html)
which is assumed by GDB. My question is, is the mapping of this variable to
`array_1.0` an issue with gfortran, or does the issue lie with GDB not being
able to parse expressions for variables that would not typically be possible?
