diff options
| author | Felix Willgerodt <felix.willgerodt@intel.com> | 2023-02-13 11:02:23 +0100 |
|---|---|---|
| committer | Felix Willgerodt <felix.willgerodt@intel.com> | 2023-02-15 09:51:28 +0100 |
| commit | ecbc5c4f9059dd483cf8b0705cbd4e2e9606aad5 (patch) | |
| tree | 43827ec45e63690388b13e05cf33cfa74bddcf66 | |
| parent | c22a74728313ee35f6bf143238d42e2eca9ed020 (diff) | |
| download | binutils-ecbc5c4f9059dd483cf8b0705cbd4e2e9606aad5.zip binutils-ecbc5c4f9059dd483cf8b0705cbd4e2e9606aad5.tar.gz binutils-ecbc5c4f9059dd483cf8b0705cbd4e2e9606aad5.tar.bz2 | |
gdb, fortran: Fix quad floating-point type for ifort compiler.
I fixed this a while ago for ifx, one of the two Intel compilers, in
8d624a9d8050ca96e154215c7858ac5c2d8b0b19.
Apparently I missed that the older ifort Intel compiler actually emits
slightly different debug info again:
0x0000007a: DW_TAG_base_type
DW_AT_byte_size (0x20)
DW_AT_encoding (DW_ATE_complex_float)
DW_AT_name ("COMPLEX(16)")
0x00000081: DW_TAG_base_type
DW_AT_byte_size (0x10)
DW_AT_encoding (DW_ATE_float)
DW_AT_name ("REAL(16)")
This fixes two failures in gdb.fortran/complex.exp with ifort.
Approved-By: Tom Tromey <tom@tromey.com>
| -rw-r--r-- | gdb/i386-tdep.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index da4950a..acf22db 100644 --- a/gdb/i386-tdep.c +++ b/gdb/i386-tdep.c @@ -8238,12 +8238,14 @@ i386_floatformat_for_type (struct gdbarch *gdbarch, || strcmp (name, "_Float128") == 0 || strcmp (name, "complex _Float128") == 0 || strcmp (name, "complex(kind=16)") == 0 + || strcmp (name, "COMPLEX(16)") == 0 || strcmp (name, "complex*32") == 0 || strcmp (name, "COMPLEX*32") == 0 || strcmp (name, "quad complex") == 0 || strcmp (name, "real(kind=16)") == 0 || strcmp (name, "real*16") == 0 - || strcmp (name, "REAL*16") == 0) + || strcmp (name, "REAL*16") == 0 + || strcmp (name, "REAL(16)") == 0) return floatformats_ieee_quad; return default_floatformat_for_type (gdbarch, name, len); |