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

griesemer opened this issue Feb 2, 2021 · 2 comments


Copy link

@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

@griesemer griesemer added the NeedsDecision label Feb 2, 2021
@griesemer griesemer added this to the Unreleased milestone Feb 2, 2021
@griesemer griesemer self-assigned this Feb 2, 2021
Copy link

@gopherbot gopherbot commented Apr 29, 2021

Change 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

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
Trust: Robert Griesemer <>
Reviewed-by: Ian Lance Taylor <>
Copy link

@gopherbot gopherbot commented May 1, 2021

Change 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

Updates #44057.
Updates #44058.

Change-Id: I0b071e8ee7a1c97aae2436945cc9583cde3b40b0
Trust: Robert Griesemer <>
Trust: Emmanuel Odeke <>
Reviewed-by: Matthew Dempsky <>
Reviewed-by: Russ Cox <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants