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: fails to bootstrap with go1.21.9 at 15cec430d7 #66874

Closed
pmur opened this issue Apr 17, 2024 · 11 comments
Closed

cmd/compile: fails to bootstrap with go1.21.9 at 15cec430d7 #66874

pmur opened this issue Apr 17, 2024 · 11 comments
Assignees
@griesemer
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. Soon This needs to be done soon. (regressions, serious bugs, outages)
Milestone
Go1.23

Comments

@pmur
Copy link
Contributor

pmur commented Apr 17, 2024

Go version

master

Output of go env in your module/workspace:

GOARCH=ppc64le and GOARCH=amd64
GOOS=linux

What did you do?

# checkout upstream go commit 076166ab4e
GOROOT_BOOTSTRAP=~/path/to/go1.21.9 ./make.bash

What did you see happen?

Building Go cmd/dist using /home/murp/go-bootstrap-121. (go1.21.9 linux/ppc64le)
Building Go toolchain1 using /home/murp/go-bootstrap-121.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
<unknown line number>: internal compiler error: panic: godebug: Value of name not listed in godebugs.All: gotypesalias

goroutine 1 [running]:
runtime/debug.Stack()
	/home/murp/go-bootstrap-121/src/runtime/debug/stack.go:24 +0x6c
bootstrap/cmd/compile/internal/base.FatalfAt({0x2152c?, 0x0?}, {0x79e1fb, 0x9}, {0xc000186c80, 0x1, 0x1})
	/home/murp/git/go/src/cmd/compile/internal/base/print.go:225 +0x270
bootstrap/cmd/compile/internal/base.Fatalf(...)
	/home/murp/git/go/src/cmd/compile/internal/base/print.go:194
bootstrap/cmd/compile/internal/gc.handlePanic()
	/home/murp/git/go/src/cmd/compile/internal/gc/main.go:52 +0xa4
panic({0x6f3260?, 0xc00003ca00?})
	/home/murp/go-bootstrap-121/src/runtime/panic.go:914 +0x27c
internal/godebug.(*Setting).Value.func1()
	/home/murp/go-bootstrap-121/src/internal/godebug/godebug.go:141 +0xf4
sync.(*Once).doSlow(0xc0000de401?, 0x5c4864?)
	/home/murp/go-bootstrap-121/src/sync/once.go:74 +0x110
sync.(*Once).Do(...)
	/home/murp/go-bootstrap-121/src/sync/once.go:65
internal/godebug.(*Setting).Value(0xcb9180)
	/home/murp/go-bootstrap-121/src/internal/godebug/godebug.go:138 +0x78
bootstrap/cmd/compile/internal/types2.NewChecker(0x7fffffffe898?, 0xc000466120, 0x0?)
	/home/murp/git/go/src/cmd/compile/internal/types2/check.go:261 +0x8c
bootstrap/cmd/compile/internal/types2.(*Config).Check(0x79be6d?, {0x7fffffffe898?, 0x7a6074?}, {0xc00009c598, 0x1, 0x1}, 0x1d8d88?)
	/home/murp/git/go/src/cmd/compile/internal/types2/api.go:470 +0x98
bootstrap/cmd/compile/internal/noder.checkFiles({0x0, {0x0, 0x0}}, {0xc00009c528, 0x1, 0x18?})
	/home/murp/git/go/src/cmd/compile/internal/noder/irgen.go:93 +0x5a0
bootstrap/cmd/compile/internal/noder.writePkgStub({0x0?, {0x0?, 0x0?}}, {0xc00009c528, 0x1, 0x1})
	/home/murp/git/go/src/cmd/compile/internal/noder/unified.go:304 +0x7c
bootstrap/cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0xc00009c528?, 0x6e2500?, 0x0?})
	/home/murp/git/go/src/cmd/compile/internal/noder/unified.go:180 +0xf4
bootstrap/cmd/compile/internal/noder.LoadPackage({0xc00001e1d0, 0x1, 0x1})
	/home/murp/git/go/src/cmd/compile/internal/noder/noder.go:77 +0x468
bootstrap/cmd/compile/internal/gc.Main(0x7d72b0)
	/home/murp/git/go/src/cmd/compile/internal/gc/main.go:197 +0xce0
main.main()
	/home/murp/git/go/src/cmd/compile/main.go:57 +0x134

What did you expect to see?

A few lines indicating the toolchain bootstrapped.
@pmur
Copy link
Contributor Author

pmur commented Apr 17, 2024

@griesemer FYI, this is causing CI failures for ppc64x and a few others which bootstrap with 1.21.9.

@cherrymui
Copy link
Member

With the revert CL https://go.dev/cl/579575 submitted, is it still failing? Thanks.

@cherrymui cherrymui added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 17, 2024
@pmur
Copy link
Contributor Author

pmur commented Apr 17, 2024

Yes, the CI is still continuing to fail bootstrap. It failed on amd64 and ppc64le at 076166ab4e when I tried it.

@cherrymui cherrymui added NeedsFix The path to resolution is known, but the work has not been done. Soon This needs to be done soon. (regressions, serious bugs, outages) and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 17, 2024
@cherrymui cherrymui added this to the Go1.23 milestone Apr 17, 2024
@cherrymui
Copy link
Member

Okay, thanks.

@cherrymui cherrymui changed the title cmd/go: fails to bootstrap with go1.21.9 at 15cec430d7 cmd/compile: fails to bootstrap with go1.21.9 at 15cec430d7 Apr 17, 2024
@cherrymui cherrymui added the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 17, 2024
@ianlancetaylor
Copy link
Contributor

CC @griesemer @alandonovan @findleyr Same as #66873 ?

@griesemer
Copy link
Contributor

griesemer commented Apr 17, 2024 •
edited

I don't think it's the same as #66873: that one is related to enabled type alias nodes, while this is about bootstrapping. This looks similar to the problem encountered here: https://go.dev/cl/579575 .

This failure seems to be related to the way gotypesalias is declared in the code (in cmd/compile/internal/types2/check.go:27):

godebug.New("gotypesalias")

vs

godebug.New("#gotypesalias") // note the #

It's not clear why the # is needed because the flag is in the table (contrary to the error message reported). There may be a bug in the handling of # for GODEBUG settings.

@griesemer
Copy link
Contributor

griesemer commented Apr 17, 2024 •
edited

I note that https://go.dev/cl/579076/ removed the # from the godebug.New("#gotypesalias") because the most up-to-date flag setting is not seen when bootstrapping with 1.20 and the # is present (the respective godebug changes happened in https://go.dev/cl/476280). I suspect there's an issue here with the handling of #.

@cherrymui
Copy link
Member

The internal/godebug package is not listed as a bootstrap package (not in this list https://cs.opensource.google/go/go/+/master:src/cmd/dist/buildtool.go;l=33), so at bootstrapping, it uses the bootstrap toolchain's (Go 1.21.9) internal/godebug package, instead of the one in GOROOT. This is also seen in the stack trace above

internal/godebug.(*Setting).Value(0xcb9180)
	/home/murp/go-bootstrap-121/src/internal/godebug/godebug.go:138 +0x78
bootstrap/cmd/compile/internal/types2.NewChecker(0x7fffffffe898?, 0xc000466120, 0x0?)
	/home/murp/git/go/src/cmd/compile/internal/types2/check.go:261 +0x8c

It is internal/godebug, not bootstrap/internal/godebug.

We can't simply add internal/godebug to the list, as internal/godebug uses runtime functions that doesn't exist in the bootstrap runtime... Maybe there is a way around? I'm not sure. Perhaps we can make it godebug.New("#gotypesalias") (with #) just for bootstrapping (with compiler_bootstrap build tag), then build regular compiler without #.

@gopherbot
Copy link

Change https://go.dev/cl/579835 mentions this issue: cmd/compile: use #gotypesalias for bootstrap

@griesemer griesemer self-assigned this Apr 17, 2024
@gopherbot
Copy link

Change https://go.dev/cl/579875 mentions this issue: types2: don't access gotypesalias during bootstrap (before 1.22)

@gopherbot
Copy link

Change https://go.dev/cl/579935 mentions this issue: go/types, types2: use types2.Config flag to control Alias node creation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@griesemer griesemer

Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. Soon This needs to be done soon. (regressions, serious bugs, outages)
Projects
None yet
Milestone
Go1.23
Development

No branches or pull requests
5 participants
@ianlancetaylor @griesemer @gopherbot @pmur @cherrymui