CL fails to bootstrap from Go 1.4; succeeds with 1.5+

[Matthew Dempsky]

I have a fairly mechanical refactoring CL (golang.org/cl/20677) that successfully bootstraps with Go 1.5+, but fails with Go 1.4 due to what appear to be memory corruption errors.  Using git bisect, I found golang.org/cl/10118 is the magic CL that allows me to bootstrap reliably.

I spent a little while trying to find ways to tweak my CL to make it still work with Go 1.4.  I also tried changing cmd/dist to build the bootstrap toolchain with -gcflags=-N.  No luck so far.

At this point, how should I proceed?

Options I see:

1. Continue experimenting with my CL until I (hopefully) find a variation that avoids hitting the Go 1.4 memory corruption bug.

2. Backport CL 10118 to the Go 1.4 release branch.

3. Bump the required bootstrap toolchain to 1.5+.

4. Abandon my CL and cross my fingers we don't hit the issue again in the future.

[minux]

I feel that 3 is unacceptable (I don't want to complicate the already complicated

bootstrap story any further, and I know there are people who just don't use any

pre-built binaries except for the bare essentials). I vote for either 1 or 2.

2 is better, but perhaps CL 10118 is too big a change to backport to the C toolchain?

[Ian Lance Taylor]

Can we change cmd/dist to pass an option to the 1.4 compiler to
disable escape analysis? We don't really care about the performance
of the code compiled by the 1.4 compiler.

Ian

[Matthew Dempsky]

On Mon, Mar 14, 2016 at 8:00 AM, Ian Lance Taylor <ia...@golang.org> wrote:

Can we change cmd/dist to pass an option to the 1.4 compiler to

disable escape analysis?  We don't really care about the performance
of the code compiled by the 1.4 compiler.

That's what I was hoping adding -gcflags=-N to

            // Run Go 1.4 to build binaries.

            run(workspace, ShowOutput|CheckExit, pathf("%s/bin/go", goroot_bootstrap), "install", "-v", "bootstrap/...")

in cmd/dist/buildtool.go might do, but still fails.

Looking at the Go 1.4 sources, it appears escape analysis and dependent code runs unconditionally.

[Ian Lance Taylor]

Bother. OK, do you know which specific part of your CL is miscompiled
by 1.4? Let's pin down precisely what goes wrong. CL 10118 is not
described as a bug fix, though of course it may be one.

Ian

[Brad Fitzpatrick]

Which version of Go 1.4? IIRC, we require Go 1.4.3 due to a bug in earlier versions.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Dempsky]

On Mon, Mar 14, 2016 at 9:35 AM, Ian Lance Taylor <ia...@golang.org> wrote:

Bother.  OK, do you know which specific part of your CL is miscompiled

by 1.4?

Not yet.  I suspected it would be my changes to substAny, because that's the only really non-trivial part of the CL and it involves slices.  I'm trying to narrow it down right now.

[Matthew Dempsky]

On Mon, Mar 14, 2016 at 9:42 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

Which version of Go 1.4? IIRC, we require Go 1.4.3 due to a bug in earlier versions.

Hm, I'd been testing with Go 1.4 proper, but I just verified that I still have the same issue with Go 1.4.3.  (Specifically, I originally tested with the "go1.4" Git tag, mistaking it for the Go 1.4 release branch.  I've now tested with the "go1.4.3" git tag too, and it fails in the same way.)

[Matthew Dempsky]

Still unclear the root cause, but I discovered that building the bootstrap toolchain with -gcflags=-l to disable inlining at least makes it work with Go 1.4.3.  That seems like a reasonable solution to me?

[Brad Fitzpatrick]

Sure.