-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: arm64 cross-compilation errors "branch too far" #13579
Comments
I'm not sure #12540 should have been closed - although it managed to compile the test case I attached, it still can't compile my internal codebase. Pleased to see you have a "real" test case that breaks. |
Looking at the errors and the gist file you've attached, this is an almost identical issue to that which I see on my internal codebase. For me this means that the arm64 branch is broken. I'm happy to test any fixes on my internal codebase in addition to the testcase you've got attached here. |
Yes, it is sad. Russ, why did you set Unplanned? @rsc FWIW to workaround this bug I currently use: func initCalls() {
func() {
Calls = append(Calls, &Call{ID: 0, Name: "open", CallName: "open", Ret: ResourceType{TypeCommon: TypeCommon{TypeName: "ret", IsOptional: false}, Kind: ResFD, Subkind: ResAny}, Args: []Type{PtrType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}, Dir: DirIn, Type: FilenameType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}}}, FlagsType{TypeCommon: TypeCommon{TypeName: "flags", IsOptional: false}, TypeSize: 0, Vals: []uintptr{0, 1, 2, 1024, 8192, 524288, 64, 16384, 65536, 128, 0, 262144, 256, 131072, 2048, 2097152, 1052672, 512}}, FlagsType{TypeCommon: TypeCommon{TypeName: "mode", IsOptional: false}, TypeSize: 0, Vals: []uintptr{256, 128, 64, 32, 16, 8, 4, 2, 1}}}})
}()
func() {
Calls = append(Calls, &Call{ID: 1, Name: "open$dir", CallName: "open", Ret: ResourceType{TypeCommon: TypeCommon{TypeName: "ret", IsOptional: false}, Kind: ResFD, Subkind: FdDir}, Args: []Type{PtrType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}, Dir: DirIn, Type: FilenameType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}}}, FlagsType{TypeCommon: TypeCommon{TypeName: "flags", IsOptional: false}, TypeSize: 0, Vals: []uintptr{0, 1, 2, 1024, 8192, 524288, 64, 16384, 65536, 128, 0, 262144, 256, 131072, 2048, 2097152, 1052672, 512}}, FlagsType{TypeCommon: TypeCommon{TypeName: "mode", IsOptional: false}, TypeSize: 0, Vals: []uintptr{256, 128, 64, 32, 16, 8, 4, 2, 1}}}})
}()
func() {
Calls = append(Calls, &Call{ID: 2, Name: "openat", CallName: "openat", Ret: ResourceType{TypeCommon: TypeCommon{TypeName: "ret", IsOptional: false}, Kind: ResFD, Subkind: ResAny}, Args: []Type{ResourceType{TypeCommon: TypeCommon{TypeName: "fd", IsOptional: false}, Kind: ResFD, Subkind: FdDir}, PtrType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}, Dir: DirIn, Type: FilenameType{TypeCommon: TypeCommon{TypeName: "file", IsOptional: false}}}, FlagsType{TypeCommon: TypeCommon{TypeName: "flags", IsOptional: false}, TypeSize: 0, Vals: []uintptr{0, 1, 2, 1024, 8192, 524288, 64, 16384, 65536, 128, 0, 262144, 256, 131072, 2048, 2097152, 1052672, 512}}, FlagsType{TypeCommon: TypeCommon{TypeName: "mode", IsOptional: false}, TypeSize: 0, Vals: []uintptr{256, 128, 64, 32, 16, 8, 4, 2, 1}}}})
}()
... |
It's Unplanned because arm64 is still an experimental (unstaffed) port and the reproduction case is huge. Now that I look at the case a second time I see that it's not a randomly generated program. On first glance I had thought it was. I will change this to Go1.6Maybe but no promises. |
My reproduction case was auto generated, because I wasn't in a position to release the source, interestingly Dmitry's code is doing something incredibly similar and gets an identical branch too far message. |
Debugging into this a bit - it seems that at least some of the offending "branch too far" errors are coming from calls to omovlit, when the assembler is trying to insert a load literal; hence the output of MOVD etc. The brdist is failing because the offset between the MOVD and the literal is out of the range of a 19 bit immediate. I have yet to discover why this happens - I'm not completely familiar with this code or when/how the literal pools get flushed and adjusted as we insert ops. |
CL https://golang.org/cl/18972 mentions this issue. |
I can confirm that after @rsc adjusted the literal pool calculations (cl 18972 mentioned above) that my internal codebase now compiles cleanly on arm64 with that patch applied to go version devel +aff6aa0 Tue Jan 26 21:04:27 2016 +0000 linux/amd64 |
@rsc thanks for fixing this! |
There is a similar fixed issue #12540, but I am on "go version devel +7ba85b5 Fri Dec 11 12:09:49 2015 +0100 linux/amd64" and hit the same compiler bug.
Here is the source:
https://gist.github.com/dvyukov/42bc81d1057c88fb6dcf
The text was updated successfully, but these errors were encountered: