diff options
author | Giuliano Belinassi <giuliano.belinassi@usp.br> | 2020-08-22 17:43:43 -0300 |
---|---|---|
committer | Giuliano Belinassi <giuliano.belinassi@usp.br> | 2020-08-22 17:43:43 -0300 |
commit | a926878ddbd5a98b272c22171ce58663fc04c3e0 (patch) | |
tree | 86af256e5d9a9c06263c00adc90e5fe348008c43 /libgo/go/strconv/extfloat.go | |
parent | 542730f087133690b47e036dfd43eb0db8a650ce (diff) | |
parent | 07cbaed8ba7d1b6e4ab3a9f44175502a4e1ecdb1 (diff) | |
download | gcc-devel/autopar_devel.zip gcc-devel/autopar_devel.tar.gz gcc-devel/autopar_devel.tar.bz2 |
Merge branch 'autopar_rebase2' into autopar_develdevel/autopar_devel
Quickly commit changes in the rebase branch.
Diffstat (limited to 'libgo/go/strconv/extfloat.go')
-rw-r--r-- | libgo/go/strconv/extfloat.go | 24 |
1 files changed, 23 insertions, 1 deletions
diff --git a/libgo/go/strconv/extfloat.go b/libgo/go/strconv/extfloat.go index 2a2dd7a..793a34d 100644 --- a/libgo/go/strconv/extfloat.go +++ b/libgo/go/strconv/extfloat.go @@ -231,8 +231,30 @@ var uint64pow10 = [...]uint64{ // float32 depending on flt. func (f *extFloat) AssignDecimal(mantissa uint64, exp10 int, neg bool, trunc bool, flt *floatInfo) (ok bool) { const uint64digits = 19 + + // Errors (in the "numerical approximation" sense, not the "Go's error + // type" sense) in this function are measured as multiples of 1/8 of a ULP, + // so that "1/2 of a ULP" can be represented in integer arithmetic. + // + // The C++ double-conversion library also uses this 8x scaling factor: + // https://github.com/google/double-conversion/blob/f4cb2384/double-conversion/strtod.cc#L291 + // but this Go implementation has a bug, where it forgets to scale other + // calculations (further below in this function) by the same number. The + // C++ implementation does not forget: + // https://github.com/google/double-conversion/blob/f4cb2384/double-conversion/strtod.cc#L366 + // + // Scaling the "errors" in the "is mant_extra in the range (halfway ± + // errors)" check, but not scaling the other values, means that we return + // ok=false (and fall back to a slower atof code path) more often than we + // could. This affects performance but not correctness. + // + // Longer term, we could fix the forgot-to-scale bug (and look carefully + // for correctness regressions; https://codereview.appspot.com/5494068 + // landed in 2011), or replace this atof algorithm with a faster one (e.g. + // Ryu). Shorter term, this comment will suffice. const errorscale = 8 - errors := 0 // An upper bound for error, computed in errorscale*ulp. + + errors := 0 // An upper bound for error, computed in ULP/errorscale. if trunc { // the decimal number was truncated. errors += errorscale / 2 |