cmd/compile: obscure error messages for large constants #6648
Labels
Milestone
Comments
We should make the error message better. That said, the compiler is not required to handle this case. Those are integers, not floating-point numbers, and the compiler is only required to handle integers up to 2^128 (2x the precision of the largest run-time int type). Labels changed: added priority-later, removed priority-triage. Status changed to Accepted. |
rsc
changed the title
|
I don't think this issue exists anymore at least on go1.6 given program https://play.golang.org/p/zxKzI4HJFz or inlined package main
import (
"fmt"
"runtime"
)
var f = []float64{
47634102635436893179040485073748265163400240214004076398607741693502376385799646303105256699577209032590132615988260237052123652332890095616,
12438414054641300055918190849808704283732243800785472203727097932000687811897290487171609691949473988773572358313712866199772466321053448142848,
}
func main() {
fmt.Printf("Version: %s\n[0]=%f [1]=%f\n", runtime.Version(), f[0], f[1])
}$ go run main.go
Version: devel +c80e0d3 Wed Jul 27 05:43:36 2016 +0000
[0]=47634102635436893179040485073748265163400240214004076398607741693502376385799646303105256699577209032590132615988260237052123652332890095616.000000 [1]=12438414054641300055918190849808704283732243800785472203727097932000687811897290487171609691949473988773572358313712866199772466321053448142848.000000When I upgrade to a larger constant to make it fail to compile, I get an improved error message given program https://play.golang.org/p/TMQxSJdr85 package main
import (
"fmt"
"runtime"
)
var f = []float64{
47634102635436893171818181818181818818181818181818273737379040485073748265163400240214004076398607741693502376385799646303105256699577209032590132615988260237052123652332890095616,
12438414054641300055918190849808704283732243800785472203727097932000687811897290487171609691949473988773572358313712866199772466321053448142848,
}
func main() {
fmt.Printf("Version: %s\n[0]=%f [1]=%f\n", runtime.Version(), f[0], f[1])
}$ go run main.go
# command-line-arguments
./TMQxSJdr85.go:9: constant too large: 47634102635436893171818181818181818818181818181818273737379040485073748265163400240214004076398607741693502376385799646303105256699577209032590132615988260237052123652332890095616
./TMQxSJdr85.go:9: overflow in constant
./TMQxSJdr85.go:9: constant Inf overflows float64It seems like this issue was fixed by commit ed1a5e5 and CL https://go-review.googlesource.com/#/c/19962 by @griesemer. |
|
Thanks for investigating, @odeke-em. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by borman@google.com:
Issue filed on suggestion of Ian What steps will reproduce the problem? Build the following package: package b var f = []float64 { 47634102635436893179040485073748265163400240214004076398607741693502376385799646303105256699577209032590132615988260237052123652332890095616, 12438414054641300055918190849808704283732243800785472203727097932000687811897290487171609691949473988773572358313712866199772466321053448142848, } What is the expected output? A more meaningful error message (ideally no message, theoretically it should compile) Appending a .0 to both constants results in the code compiling correctly. What do you see instead? The first element generates the messages: ./b.go:4: constant addition overflow ./b.go:4: overflow in constant The second element generates the messages: ./b.go:5: constant multiplication overflow ./b.go:5: overflow in constant If the first element is commented out the second element generates: ./b.go:5: ovf in mpaddxx ./b.go:5: constant multiplication overflow ./b.go:5: overflow in constant Which compiler are you using (5g, 6g, 8g, gccgo)? standard compiler, 6g Which operating system are you using? Mac OSX 10.8.5 Which version are you using? (run 'go version') go version go1.2rc2 darwin/amd64 Please provide any additional information below. The first constant is 2^464, the second is 92! Both of these values can be represented in a float64 without loss of precision.The text was updated successfully, but these errors were encountered: