tree 5a2e2cbf92b43bef00fd5658c88c43bd5aa9a627
parent 122cf0f2d93ae6f7a53e8dd643ebb068b79df9cf
author Andrew Burgess <andrew.burgess@embecosm.com> 1556893435 +0100
committer Andrew Burgess <andrew.burgess@embecosm.com> 1558169342 +0100

gdb/fortran: Use floatformats_ia64_quad for fortran 16-byte floats

PR gdb/18644 is caused by GDB using the wrong floating point format
for gfortran's 16-byte floating point type, including when the 16-byte
float is used as the component of a 32-byte complex type.

This commit addresses the issue in two places, first in i386-tdep.c,
there is already some code to force the use of floatformats_ia64_quad
for specific named types, this is extended to include the type names
that gfortran uses for its 16-byte floats.

Second, the builtin 16-byte float type (in f-lang.c) is changed so it
no longer uses gdbarch_long_double_format.  On i386 this type is not
16-bytes, but is smaller, this is not what gfortran is expecting.
Instead we now use gdbarch_floatformat_for_type and ask for a
16-byte (128 bit) type using the common gfortran type name.  This is
then spotted in i386-tdep.c (thanks to the first change above) and we
again get floatformats_ia64_quad returned.

This patch was tested on X86-64/GNU-Linux using '--target_board=unix'
and '--target_board=unix/-m32', and resolves all of the known failures
associated with PR gdb/18644.  I've also added the test case from the
original bug report.

gdb/ChangeLog:

	PR gdb/18644:
	* f-lang.c (build_fortran_types): Use floatformats_ia64_quad for
	16-byte floats.
	* i386-tdep.c (i386_floatformat_for_type): Use
	floatformats_ia64_quad for the 16-byte floating point component
	within a fortran 32-byte complex number.

gdb/testsuite/ChangeLog:

	PR gdb/18644
	* gdb.fortran/complex.exp: Remove setup_kfail calls.
	* gdb.fortran/printing-types.exp: Add new test.
	* gdb.fortran/printing-types.f90: Add 16-byte real variable for
	testing.
	* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Remove
	setup_kfail call.