/cc @minux

Code that could be used to reproduce this would be helpful.

I'll try and generate a test case for you tomorrow, I can't upload the code under test yet sadly

Sorry for the delay... gist link to the generator code (it builds a tester.go with 20000 function stubs and a map pointing to them):

https://gist.github.com/matt2909/7c1c5880621f9c6d8775

To reproduce the compiler error I see on head:

$> go run generator.go > tester.go

/* ARM64 compiler breaks as follows */
$> GOOS=linux GOARCH=arm64 go build tester.go
//# command-line-arguments
./tester.go:1: branch too far
00012 (/xxxxx/tester.go:120015) BLS 1360280
./tester.go:1: branch too far
00172 (/xxxxx/tester.go:20007) BNE 1360252

/* AMD64 compiler behaves as expected and generates a tester executable */
$> GOOS=linux GOARCH=amd64 go build tester.go

Let me know if that is sufficient for your purposes @mwhudson ?

I can reproduce the problem, so that's good. Unfortunately I'm a little confused about what's going on and don't really have time to investigate now.

I guess some code somewhere needs to switch to a model of loading the offset into a register and branching to that rather than attempting to encode the offset as an immediate.

is it worth me taking a look? Is there anyway to understand the path though the compiler to the error? I couldn't find a good way of getting a stack trace (or any other trace) at the point of the error message.

It will most likely be in cmd/internal/obj/arm64/asm7.go

On Tue, Oct 13, 2015 at 7:28 AM, Matt Horsnell notifications@github.com
wrote:

is it worth me taking a look? Is there anyway to understand the path
though the compiler to the error? I couldn't find a good way of getting a
stack trace (or any other trace) at the point of the error message.

—
Reply to this email directly or view it on GitHub
#12540 (comment).

possibly the bit commented out about "very large branches" ?

I'm sorry, I haven't looked at that code in months, but that does sound
like a smoking gun.

On Tue, 13 Oct 2015 07:57 Matt Horsnell notifications@github.com wrote:

possibly the bit commented out about "very large branches" ?

—
Reply to this email directly or view it on GitHub
#12540 (comment).

anyway to get more context printed out as the compiler generates makes decisions on branching etc?

Nothing systematic I know about, I suspect this is the land of debugging by adding print statements.

Do you know of any documents that explain some of the compiler phases, it's APIs or structs? Flying by fmt statements is fine if I have a map of the terrain

OK, fmt statements it is then ;)

having spent a bit of time looking at this, I'm really not making progress and can't invest more effort without some guidance or compiler documentation...

“Branch too far” means that the code has generated a conditional branch to a target too far away in the code. The usual fix is to generate the opposite branch, jumping over an unconditional branch to the actual target. The code generator could and probably should do this. The x86 already does something similar to decide whether to use the long or short forms of conditional branches.

@rsc if you could point me in the right direction, i.e. which file and which part of that file, or step in the process of asm etc I need to go hunt for then I'd happily take another look.

/* My suspicion having reduced my actual code base so that it avoids this issue is that there are other bugs lurking in the arm64 branch, for serious sized applications. */

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