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.

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

x/build/cmd/coordinator: building subrepos at run repo head #16413

Closed
bradfitz opened this issue Jul 18, 2016 · 3 comments
Closed

x/build/cmd/coordinator: building subrepos at run repo head #16413

bradfitz opened this issue Jul 18, 2016 · 3 comments

Comments

@bradfitz
Copy link
Contributor

I just saw this during a trybot run:

https://storage.googleapis.com/go-build-log/25e0a367/linux-amd64_52c9862a.log

bootstrap/asm
# bootstrap/compile/internal/ssa
/tmp/workdir/go/src/cmd/compile/internal/ssa/opGen.go:8914[/tmp/workdir/go/pkg/bootstrap/src/bootstrap/compile/internal/ssa/opGen.go:8917]: cannot use []regMask literal (type []regMask) as type []outputInfo in field value
/tmp/workdir/go/src/cmd/compile/internal/ssa/opGen.go:8927[/tmp/workdir/go/pkg/bootstrap/src/bootstrap/compile/internal/ssa/opGen.go:8930]: cannot use []regMask literal (type []regMask) as type []outputInfo in field value
bootstrap/link/internal/amd64

It had never occurred on any prior run of trybots on https://go-review.googlesource.com/25001

I don't understand.

@bradfitz bradfitz changed the title cmd/compile/internal/ssa: bootstrap compile failure? x/build/cmd/coordinator: building subrepos at run repo head Jul 18, 2016
@bradfitz bradfitz assigned bradfitz and unassigned randall77 Jul 18, 2016
@bradfitz
Copy link
Contributor Author

False alarm, @randall77. This is my and @adg's fault. The coordinator is running subrepo trybot tests at the wrong repo head. It's trying to run it at:

commit 25e0a367da6254d89b497f392ea9d1679455d000
Author: Keith Randall <khr@golang.org>
Date:   Wed Jul 13 16:15:54 2016 -0700

    [dev.ssa] cmd/compile: clean up tuple types and selects

    Make tuple types and their SelectX ops fully generic.
    These ops no longer need to be lowered.
    Regalloc understands them and their tuple-generating arguments.
    We can now have opcodes returning arbitrary pairs of results.
    (And it would be easy to move to >2 results if needed.)

    Update arm implementation to the new standard.
    Implement just enough in 386 port to do 64-bit add.

    Change-Id: I370ed5aacce219c82e1954c61d1f63af76c16f79
    Reviewed-on: https://go-review.googlesource.com/24976
    Reviewed-by: Cherry Zhang <cherryyz@google.com>
    Run-TryBot: Keith Randall <khr@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>

... which is on the dev.ssa branch. It should be selecting master instead.

@bradfitz
Copy link
Contributor Author

It looks like the coordinator's findWork function sets the branch head for the "go" repo by just looking at the first item in:

https://build.golang.org/?mode=json

Which is currently:

        "revisions": [
                {
                        "repo": "go",
                        "revision": "25e0a367da6254d89b497f392ea9d1679455d000",
                        "parentRevisions": [
                                "6b6de15d327142a19c978c8b9811310b174fd60b"
                        ],
                        "date": "2016-07-18T16:11:36Z",
                        "branch": "dev.ssa",
                        "author": "Keith Randall \u003ckhr@golang.org\u003e",
                        "desc": "[dev.ssa] cmd/compile: clean up tuple types and selects\n\nMake tuple types and their SelectX ops fully generic.\nThese ops no longer need to be lowered.\nRegalloc understands them and their tuple-generating arguments.\nWe can now have opcodes returning arbitrary pairs of results.\n(And it would be easy to move to \u003e2 results if needed.)\n\nUpdate arm implementation to the new standard.\nImplement just enough in 386 port to do 64-bit add.\n\nChange-Id: I370ed5aacce219c82e1954c61d1f63af76c16f79\nReviewed-on: ",

Looks like it should prefer the first "master" branch entry instead.

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Jul 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants