Re: [RFC][06/19] Target FP: Use print_floating in tdep code

["Ulrich Weigand" <uweigand@de.ibm.com>]

Hi Maciej,

>  Thank you for your effort in getting this area right, the limitations in 
> our FP arithmetic handling really troubled me.

Thanks for testing, this is really helful!
 
>  I pushed your changes 01-06 combined through testing with a couple of 
> MIPS/Linux targets, native and crossed (from x86-64), and all have 
> consistently regressed in gdb.base/dfp-exprs.exp, e.g.:
[...]
> i.e. values to be output are missing, numerous across this test case.  No 
> other regressions though.

This is surprising.  Could you do a quick check whether the regression
is introduced with patch 6 of the series, or already with patch 5?

>  Also I find the new formatting of `info all-registers' output 
> functionally regressed (rather than merely "changed a bit"), e.g.:
[...]
> I think we need to get the ability to align output (previously achieved 
> with formatters, i.e. "%-17.9g" and "%-24.17g") restored; frankly I find 
> the new format unreadable, which makes me consider it unacceptable.

I see, this really doesn't look good.  It shouldn't be very difficult
to fix, since in part 7 of the series I actually introduce routines
to provide *formatted* output as well.  So I think I'll prepare an
updated patch set that moves patch 6 after patch 7 and uses those
formatted print routines in the MIPS back-end.  Once I've done that,
it would be good if you could re-run your tests to make sure the
regression is really fixed.

>  NB while striving for FP arithmetic to match target hardware accurately 
> we'll have to handle the two opposite qNaN vs sNaN encodings that the MIPS 
> architecture now supports, i.e. the original IEEE 754-1985 format with the 
> quiet bit being 0 and the recent IEEE 754-2008 format with the quiet bit 
> being 1.  This obviously has to be taken into account in calculations, 
> according to the hardware mode being active (or the relevant ELF file 
> header flag in the binary chosen to debug if not connected to any target), 
> and I do hope MPFR can be switched at the run time to do the right thing.
> 
>  This can of course be the next step, once we've settled on the base 
> implementation -- and I'll take care of the MIPS architecture bits.

Agreed.  Once the new infrastructure is in place, there will be one
central place where target-specific FP arithmetic tweaks can be
implemented.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com