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.

Sign up for GitHub

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

Jump to bottom

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

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

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

griesemer opened this issue Feb 2, 2021 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unreleased

Comments

@griesemer
Copy link
Contributor

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
@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Feb 2, 2021
@griesemer griesemer added this to the Unreleased milestone Feb 2, 2021
@griesemer griesemer self-assigned this Feb 2, 2021
@jeremyfaller jeremyfaller mentioned this issue Feb 2, 2021
Open
@gopherbot
Copy link
Contributor

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
@griesemer
math: increase precision of math.SmallestNonzeroFloat64
3498027 
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 <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
@gopherbot
Copy link
Contributor

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
@griesemer
math: replace float32/64 extrema with exact expressions
7b768d4 
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 <[email protected]>
Trust: Emmanuel Odeke <[email protected]>
Reviewed-by: Matthew Dempsky <[email protected]>
Reviewed-by: Russ Cox <[email protected]>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@mknyszek mknyszek moved this to Triage Backlog in Go Compiler / Runtime Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Unreleased
Development

No branches or pull requests
2 participants
@griesemer @gopherbot