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 · 0 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant