[v3] Return of the son of fp printing.

[Jerry Quinn]

Phil Edwards writes:
 > Perhaps we should coordinate with the Fortran people and push for its
 > inclusion?  If it would save us huge chunks of labor, that sounds like
 > a maintainence win.

Having GMP would eventually let us remove any dependence on a system sprintf
implementation.  So, I'm generally in favor of it.

 > Question:  Assume that GMP is available, then how much of this do we still
 > want?  Do we:
 > 
 > 1) keep __convert_from_v as our fallback, or
 > 2) use this work as a fallback, or
 > 3) just say "hey, we're building GMP as part of the compiler installation,
 >    we know it's available, we don't need a fallback at all," or
 > 4) other.
 > 
 > If GMP goes in, it'll probably only be for 3.6 (maybe 3.5).  I wonder if
 > the floatconv.cc change is too large for 3.5?

I think using GMP for large fp printing is a long term solution (at least
3.6), not an immediate one.  If GMP becomes available, we can look at
replacing the sprintf portion of this patch with GMP-based code.  The fast
paths in floatconv.cc would remain.  Glibc already uses GMP-based code for
sprintf, and they apparently don't have these fast paths implemented.

So, the current patch will also provide a foundation for use GMP when it's
available.  At such point, convert_from_v will become ABI legacy stuff.

In the meantime, the current patch is quite self-contained.  It looks at the
fp numbers, prints directly if it meets certain criteria, then safely falls
back to sprintf.  I don't see any issues with this for 3.5, and would be happy
to see it go in 3.4 if we can figure out builtins and such.

The only other use of convert_from_v at this point is money_put.  And there,
the format string is %.0Lf.  My thought here is to convert to long when the
number is small enough, otherwise we can fall back to sprintf in the same
manner I did with this patch.  In fact, you don't even need to play the games
with the decimal point because money_put doesn't use it!

The money_put patch should be pretty simple to create and I'll try to get to
it if no one else does.  At that point, convert_from_v will remain only to
avoid breaking the library ABI.

 > >  > Mark froze the branch a couple hours ago, so we'll pretend you wrote 3.4.x
 > >  > instead.  :-)
 > > 
 > > Yeah, I just saw after posting.  Phooey.  What should the linker-map change
 > > look like now?
 > 
 > Do we want a change like this for the current release branch at all?

I'm OK with it :-)  If it can be done without breaking existing code and
within the feature set of 3.4, I think we should do it.

 > > Do we really have to uglify all the static and local stuff in a cc file?  No
 > > symbols there are going to be visible to the outside world.  And uglifying
 > > makes the code so much harder to read :-)
 > 
 > It's just that seeing non-uglified stuff inside namespace std triggers a
 > reflexive scream in me.  We could move them elsewhere?

How do you suggest?

Jerry