https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Bug ID: 120193
Summary: Incorrect debug info for unsigned(kind=1) and
unsigned(kind=4)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
unsigned(kind=1) :: a(2), e
unsigned(kind=2) :: b(2), f
unsigned(kind=4) :: c(2), g
unsigned(kind=8) :: d(2), h
a = 1u_1
b = 1u_2
c = 1u_4
d = 1u_8
e = 1u_1
f = 1u_2
g = 1u_4
h = 1u_8
end
./f951 -quiet -g -dA a.f90 -funsigned -o - | grep -A3 DW_TAG_base_type | grep
DW_AT_name
.long .LASF4 # DW_AT_name: "integer(kind=4)"
.long .LASF5 # DW_AT_name: "character(kind=1)"
.long .LASF6 # DW_AT_name: "integer(kind=8)"
.long .LASF7 # DW_AT_name: "unsigned(kind=2)"
.long .LASF8 # DW_AT_name: "character(kind=4)"
.long .LASF9 # DW_AT_name: "unsigned(kind=8)"
As you can see, unsigned(kind=2) and unsigned(kind=8) is properly in there, but
instead of unsigned(kind=1) and unsigned(kind=4) there is character(kind=1) and
character(kind=4).
One can see it even in -fdump-tree-gimple dump:
character(kind=1) a[2];
unsigned(kind=2) b[2];
character(kind=4) c[2];
unsigned(kind=8) d[2];
character(kind=1) e;
unsigned(kind=2) f;
character(kind=4) g;
unsigned(kind=8) h;
This results in really bad debugging experience, as debuggers will try to print
the unsigned(kind=1) arrays as character(1) strings and similarly for
unsigned(kind=4).
trans-types.cc says:
/* The middle end only recognizes a single unsigned type. For
compatibility of existing test cases, let's just use the
character type. The reader of tree dumps is expected to be able
to deal with this. */
Sure, make_unsigned_type will return just one type, but can't it just
build_variant_type_copy or something similar?
