forked from Imagelibrary/binutils-gdb
34d11c682f
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.