Target FP printing: Simplify and fix print_floating
authorUlrich Weigand <ulrich.weigand@de.ibm.com>
Tue, 24 Oct 2017 15:59:22 +0000 (17:59 +0200)
committerUlrich Weigand <ulrich.weigand@de.ibm.com>
Tue, 24 Oct 2017 15:59:22 +0000 (17:59 +0200)
commitfdf0cbc2b710cb5e01249e18f5a377a55eddc39b
tree0dc5b9b5fa5f60187eb0d31b7719008ed35de31c
parent3342be5dabeeaf2218dfbf4d38f92214612436f4
Target FP printing: Simplify and fix print_floating

The print_floating routine currently makes a lot of assumptions about host
and target floating point formats.  This patch cleans up many of those.

One problem is that print_floating may currently be called with types
that are not actually floating-point types, and it tries hard to output
those as floating-point values anyway.  However, there is only one single
caller of print_floating where this can ever happen: print_scalar_formatted.
And in fact, it is much simpler to handle the case where the value to be
printed is not already of floating-point type right there.

So this patch changes print_scalar_formatted to handle the 'f' format
as follows:

- If the value to be printed is already of floating-point type, just
  call print_floating on it.

- Otherwise, if there is a standard target floating-point type of
  the same size as the value, call print_floating using that type.

- Otherwise, just print the value as if the 'f' format had not been
  specified at all.

This has the overall effect to printing everything the same way as
the old code did, but is overall a lot simpler.  (Also, it would
allow us to change the above strategy more easily, if that might
be a more intuitive user interface.  For example, in the third
case above, maybe an error would be more appropriate?)

Given that change, print_floating can become much simpler.  In particular,
we now always have a floating-point format that we can consult.  This
means we can use the floating-point format to programmatically determine
the number of digits necessary to print the value.

The current code uses a hard-coded value of 9, 17, or 35 digits.  Note
that this matches the DECIMAL_DIG values for IEEE-32, IEEE-64, and
IEEE-128.  (Actually, for IEEE-128 the correct value is 36 -- the 35
seems to be an oversight.)  The DECIMAL_DIG value is defined to be
the smallest number so that any number in the target format, when
printed to this number of digits and then scanned back into a binary
floating-point number, will result in the original value.

Now that we always have a FP format, we can just compute the DECIMAL_DIG
value using the formula from the C standard.  This will be correct for
*all* FP formats, not just the above list, and it will be correct (as
opposed to current code) if the target formats differ from the host ones.

The patch moves the new logic to a new floatformat_to_string routine
(analogous to the existing decimal_to_string).  The print_floating
routine now calls floatformat_to_string or decimal_to_string, making
the separate print_decimal_floating and generic_val_print_decfloat routines
unnecessary.

gdb/ChangeLog:
2017-10-24  Ulrich Weigand  <uweigand@de.ibm.com>

* doublest.c (floatformat_precision): New routine.
(floatformat_to_string): Likewise.
* doublest.c (floatformat_to_string): Add prototype.

* printcmd.c (print_scalar_formatted): Only call print_floating
on floating-point types.
* valprint.c: Do not include "floatformat.h".
(generic_val_print_decfloat): Remove.
(generic_val_print): Call generic_val_print_float for both
TYPE_CODE_FLT and TYPE_CODE_DECFLOAT.
(print_floating): Use floatformat_to_string.  Handle decimal float.
(print_decimal_floating): Remove, merge into floatformat_to_string.
* value.h (print_decimal_floating): Remove.

* Makefile.in: Do not build doublest.c with -Wformat-nonliteral.
gdb/ChangeLog
gdb/Makefile.in
gdb/doublest.c
gdb/doublest.h
gdb/printcmd.c
gdb/valprint.c
gdb/value.h
This page took 0.026981 seconds and 4 git commands to generate.