Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile, types2: consider increasing the internal precision limit for integer values #44057

Open
griesemer opened this issue Feb 2, 2021 · 2 comments
Assignees
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Feb 2, 2021

The compiler restricts untyped integer constants to a maximum of 512 bits (implementation restriction). It also has a (separate) and higher limit on shift counts for constant shifts. The shift limit is currently set to

const shiftBound = 1023 - 1 + 52

which permits the expression

smallestFloat64 = 1.0 / (1<<(1023 - 1 + 52))

However, while the shift count check succeeds, the shift result overflows as the integer value 1<<(1023 - 1 + 52) (before conversion to the untyped float) exceeds 512 bits.

Consider increasing the bit limit for untyped integer constants to 1100 (or the like). Then we can express these constants

smallestFloat64 = 1.0 / (1<<(1023 - 1 + 52))
maxFloat64 = 1<<1023 * (1<<53 - 1) / (1.0<<52)

exactly (as in rational numbers used by go/constant).

The change should be trivial but it will likely affect tests that expect an error at lower bounds.

If the change is made, it should be made in the compiler (typecheck/constant/go) and types2 (expr.go).

cc: @mdempsky

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 29, 2021

Change https://golang.org/cl/315170 mentions this issue: math: increase precision of math.SmallestNonzeroFloat64

gopherbot pushed a commit that referenced this issue Apr 30, 2021
The original value was rounded too early, which lead to the
surprising behavior that float64(math.SmallestNonzeroFloat64 / 2)
wasn't 0. That is, the exact compile-time computation of
math.SmallestNonzeroFloat64 / 2 resulted in a value that was
rounded up when converting to float64. To address this, added 3
more digits to the mantissa, ending in a 0.

While at it, also slightly increased the precision of MaxFloat64
to end in a 0.

Computed exact values via https://play.golang.org/p/yt4KTpIx_wP.

Added a test to verify expected behavior.

In contrast to the other (irrational) constants, expanding these
extreme values to more digits is unlikely to be important as they
are not going to appear in numeric computations except for tests
verifying their correctness (as is the case here).

Re-enabled a disabled test in go/types and types2.

Updates #44057.
Fixes #44058.

Change-Id: I8f363155e02331354e929beabe993c8d8de75646
Reviewed-on: https://go-review.googlesource.com/c/go/+/315170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented May 1, 2021

Change https://golang.org/cl/315969 mentions this issue: math: replace float32/64 extrema with exact expressions

gopherbot pushed a commit that referenced this issue May 3, 2021
Follow-up on https://golang.org/cl/315170.

Updates #44057.
Updates #44058.

Change-Id: I0b071e8ee7a1c97aae2436945cc9583cde3b40b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/315969
Trust: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants