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

libgo: regression in runtime test TestCallersNilPointerPanic on ppc64le with Go 1.14beta1 update #36696

laboger opened this issue Jan 22, 2020 · 5 comments


Copy link

@laboger laboger commented Jan 22, 2020

What version of Go are you using (go version)?

$ go version
go version go1.14beta1 gccgo (GCC) 10.0.1 20200122 (experimental) linux/ppc64le

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

go env Output
$ go env

What did you do?

run the libgo tests

What did you expect to see?

Passing tests

What did you see instead?

=== RUN TestCallersNilPointerPanic
TestCallersNilPointerPanic: callers_test.go:82: wanted [runtime.Callers runtime_test.TestCallersNilPointerPanic..func1 runtime.gopanic runtime.panicmem runtime.sigpanic runtime_test.TestCallersNilPointerPanic], got [runtime.Callers runtime_test.TestCallersNilPointerPanic..func1 runtime.gopanic runtime.panicmem runtime_test.TestCallersNilPointerPanic testing.tRunner]
--- FAIL: TestCallersNilPointerPanic (0.00s)

Copy link

@ianlancetaylor ianlancetaylor commented Jan 22, 2020

Nit: this is technically not a regression as such, as the test did not exist before the update to 1.14beta1.

Looks like the difference is that the test expects to see runtime.sigpanic on the stack, but it's not there.

Can you see whether adding //go:noinline before panicmem in libgo/go/runtime/panic.go fixes the problem?

@ianlancetaylor ianlancetaylor added this to the Gccgo milestone Jan 22, 2020
Copy link
Contributor Author

@laboger laboger commented Jan 22, 2020

Oh right, I didn't check to see if it was a new test. Do you want me to change the title?

I tried the //go:noinline suggestion and the test still failed.

Copy link

@ianlancetaylor ianlancetaylor commented Jan 22, 2020

Nah, the title doesn't matter.

I guess there is some difference in the unwind results somehow.

Copy link

@cherrymui cherrymui commented Jan 23, 2020

This test also fails with gollvm (linux/amd64). I think it is because gollvm always generate an explicit nil check first, and may optimize it out at a late stage if there is a load or store. In this test, where we do var p *int; *p = 3, the backend sees p is constant nil so the faulting branch in the explicit nil check is certainly taken, and it eliminates the load and compiles it to a call to panicmem. This happens before the optimization of nil checks.

The PPC failure is probably different, if it uses implicit nil check (which I think it does for gccgo).

Copy link

@gopherbot gopherbot commented Apr 15, 2020

Change mentions this issue: runtime: fix several minor bugs in runtime and runtime/pprof package

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.