[pushed] Avoid assertion failure due to complex type change
Tom Tromey
tromey@adacore.com
Thu Apr 2 19:19:45 GMT 2020
Tankut Baris Aktemur pointed out that the recent series to change how
complex types are handled introduced a regression.
This assert in init_complex_type was firing:
gdb_assert (TYPE_CODE (target_type) == TYPE_CODE_INT
|| TYPE_CODE (target_type) == TYPE_CODE_FLT);
The problem was that f-lang.c could call init_complex_type with a type
whose code was TYPE_CODE_ERROR.
It seemed best to me to fix this in f-lang.c, rather than to change
init_complex_type to accept error types.
Tested on x86-64 Fedora 30. I'm checking this in.
gdb/ChangeLog
2020-04-02 Tom Tromey <tromey@adacore.com>
* f-lang.c (build_fortran_types): Use arch_type to initialize
builtin_complex_s32 in the TYPE_CODE_ERROR case.
---
gdb/ChangeLog | 5 +++++
gdb/f-lang.c | 9 +++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gdb/f-lang.c b/gdb/f-lang.c
index 2ce4ad43610..6b7a5fb7dba 100644
--- a/gdb/f-lang.c
+++ b/gdb/f-lang.c
@@ -744,8 +744,13 @@ build_fortran_types (struct gdbarch *gdbarch)
= init_complex_type ("complex*8", builtin_f_type->builtin_real);
builtin_f_type->builtin_complex_s16
= init_complex_type ("complex*16", builtin_f_type->builtin_real_s8);
- builtin_f_type->builtin_complex_s32
- = init_complex_type ("complex*32", builtin_f_type->builtin_real_s16);
+
+ if (TYPE_CODE (builtin_f_type->builtin_real_s16) == TYPE_CODE_ERROR)
+ builtin_f_type->builtin_complex_s32
+ = arch_type (gdbarch, TYPE_CODE_ERROR, 256, "complex*32");
+ else
+ builtin_f_type->builtin_complex_s32
+ = init_complex_type ("complex*32", builtin_f_type->builtin_real_s16);
return builtin_f_type;
}
--
2.21.1
More information about the Gdb-patches
mailing list