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: arm64 cross-compilation errors "branch too far" #13579

Closed
dvyukov opened this issue Dec 11, 2015 · 10 comments
Closed

cmd/compile: arm64 cross-compilation errors "branch too far" #13579

dvyukov opened this issue Dec 11, 2015 · 10 comments
Labels
FrozenDueToAge
Milestone
Go1.6Maybe

Comments

@dvyukov
Copy link
Member

dvyukov commented Dec 11, 2015

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

$ GOARCH=arm64 go build -v /tmp/stress/sys.go
# command-line-arguments
/tmp/stress/sys.go:1: branch too far
00004 (/tmp/stress/sys.go:1061) CMP $-1314, R1
/tmp/stress/sys.go:1: branch too far
00032 (/tmp/stress/sys.go:1061) MOVD    $228912, R3
/tmp/stress/sys.go:1: branch too far
00052 (/tmp/stress/sys.go:1061) SUB $228080, RSP
/tmp/stress/sys.go:1: branch too far
00108 (/tmp/stress/sys.go:1061) ADD $228080, RSP
/tmp/stress/sys.go:1: branch too far
00292 (/tmp/stress/sys.go:5)    MOVD    $"".autotmp_1256-81440(SP), R0
/tmp/stress/sys.go:1: branch too far
00588 (/tmp/stress/sys.go:5)    MOVD    $"".autotmp_1257-177024(SP), R0
/tmp/stress/sys.go:1: branch too far
00624 (/tmp/stress/sys.go:5)    MOVD    $"".autotmp_1258-37624(SP), R0
/tmp/stress/sys.go:1: branch too far
00652 (/tmp/stress/sys.go:5)    ADD $-8, R1
/tmp/stress/sys.go:1: branch too far
00660 (/tmp/stress/sys.go:5)    ADD $-8, R0
/tmp/stress/sys.go:1: branch too far
00720 (/tmp/stress/sys.go:5)    MOVD    $"".autotmp_1258-37624(SP), R0
/tmp/stress/sys.go:1: too many errors
@dvyukov
Copy link
Member Author

dvyukov commented Dec 11, 2015

@minux @mwhudson @davecheney @rsc

@rsc rsc added this to the Unplanned milestone Dec 28, 2015
@matt2909
Copy link
Contributor

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.

@matt2909
Copy link
Contributor

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.

@dvyukov
Copy link
Member Author

dvyukov commented Jan 22, 2016

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}}}})
        }()
...

@rsc
Copy link
Contributor

rsc commented Jan 22, 2016

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.

@rsc rsc modified the milestones: Go1.6Maybe, Unplanned Jan 22, 2016
@matt2909
Copy link
Contributor

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.

@matt2909
Copy link
Contributor

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.

@gopherbot
Copy link

CL https://golang.org/cl/18972 mentions this issue.

@matt2909
Copy link
Contributor

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

@matt2909
Copy link
Contributor

@rsc thanks for fixing this!

@golang golang locked and limited conversation to collaborators Feb 3, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.6Maybe
Development

No branches or pull requests
4 participants
@rsc @matt2909 @dvyukov @gopherbot