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

cmd/go: 'go test -gcflags=all=-l' appears not to disable inlining #27551

Closed
houxl123 opened this issue Sep 7, 2018 · 14 comments

Comments

Projects
None yet
3 participants
@houxl123
Copy link

commented Sep 7, 2018

Please answer these questions before submitting your issue. Thanks!

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

go1.11

Does this issue reproduce with the latest release?

yes

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

ubuntu 18.4

What did you do?

Go test, however, failed because of a mock. The reason for the failure of go test is that a function in a dependent package in /vendor USES inlining, and the use of go test -gcflags=all=-l in go1.10 disables inlining, but it does not work in go1.11

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

What did you expect to see?

Go test relies on the package to disable inline in go1.11

What did you see instead?

go test -gcflags=all=-l, it doesn't work to disable dependency package inlining in go1.11

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2018

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 7, 2018

@davecheney Sorry, I have already modified it.
go test -gcflags=all=-l

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2018

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 7, 2018

@davecheney Thank you very much for your answer, from go build -gcflags=all=-l -v does show that the dependent package is compiled, go test -gcflags=all="-l -v" does not work . Is it possible that go test and go build are handled differently? . Below is my go version and computer version.
go version go1.11 linux/amd64
Linux myname-linux 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 7, 2018

go test -gcflags=all="-l -v" is semantically very different from go test -gcflags=all=-l -v. The latter is equivalent to go test "-gcflags=all=-l" -v

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 7, 2018

Can we step up a level, though? Why/how does the test require that inlining be disabled?
Inlining should not generally affect the behavior of the program according to the Go spec.

The only visible difference should be in the behavior of runtime.FuncForPC, but packages (and tests) should not rely on that for semantic behavior (see #19426).

@bcmills bcmills added this to the Go1.11.1 milestone Sep 7, 2018

@bcmills bcmills changed the title Go1.11 disables dependency package inlining cmd/go: 'go test -gcflags=all=-l' appears not to disable inlining Sep 7, 2018

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 7, 2018

it doesn't work to disable dependency package inlining in go1.11

Could you please provide some more detail? How did you determine whether the package or function in question was actually inlined?

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 9, 2018

@bcmills Thank you very much for your answer, because I am sorry that I did not respond in time. I executed go test -gcflags=all="-m -l" mypkg to show that no function was inlined, indicating that inlining was disabled. But in my test case, go test mypkg failed because a function mock failed, go test -gcflags=-l mypkg was executed in go1.9, and go test -gcflags was executed in go1.10 =all=-l mypkg to succeed, but in go1.11, I tried a lot of methods go test still failed.

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 12, 2018

@davecheney @bcmills Thank you for your answer. After testing, -gcflags=all="-l" in go1.11 does disable inlining.

@houxl123 houxl123 closed this Sep 12, 2018

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 17, 2018

@davecheney @bcmills Thank you very much for your previous answer, I found the reason for the problem, go1.11 version, -gcflags=all=-l in some cases did not disable inlining, I wrote a very simple demo, which is in Http server inline does not take effect, other circumstances are effective, I hope you can help look down
https://github.com/houxl123/test_inline/

@houxl123 houxl123 reopened this Sep 17, 2018

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2018

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 17, 2018

@davecheney -gclfacgs="-l -m" does show that no function is inlined, but by executing the test case, it is found that the code for -gclfacgs="-l -m" in http server is disabled.

$ go test -gcflags="-l -m" test_inline/test
# test_inline/test [test_inline/test.test]
test/handle_test.go:15:14: handle.Max escapes to heap
test/handle_test.go:15:14: handle.MaxAddOne escapes to heap
test/handle_test.go:19:4: t.common escapes to heap
test/handle_test.go:14:17: leaking param: t
test/handle_test.go:19:10: result escapes to heap
test/handle_test.go:21:4: t.common escapes to heap
test/handle_test.go:21:8: result escapes to heap
test/handle_test.go:19:10: TestHandle ... argument does not escape
test/handle_test.go:21:8: TestHandle ... argument does not escape
test/handle_test.go:27:14: handle.Max escapes to heap
test/handle_test.go:27:14: handle.MaxAddOne escapes to heap
test/handle_test.go:28:47: http.HandlerFunc(handle.SayMax) escapes to heap
test/handle_test.go:34:4: t.common escapes to heap
test/handle_test.go:25:15: leaking param: t
test/handle_test.go:34:10: err escapes to heap
test/handle_test.go:38:34: resp.Body escapes to heap
test/handle_test.go:40:4: t.common escapes to heap
test/handle_test.go:40:10: err escapes to heap
test/handle_test.go:46:4: t.common escapes to heap
test/handle_test.go:46:10: result escapes to heap
test/handle_test.go:44:18: string(body) escapes to heap
test/handle_test.go:48:4: t.common escapes to heap
test/handle_test.go:48:8: result escapes to heap
test/handle_test.go:34:10: TestHttp ... argument does not escape
test/handle_test.go:40:10: TestHttp ... argument does not escape
test/handle_test.go:46:10: TestHttp ... argument does not escape
test/handle_test.go:48:8: TestHttp ... argument does not escape
# test_inline/test.test
/tmp/go-build007585210/b001/_testmain.go:42:42: testdeps.TestDeps literal escapes to heap
--- FAIL: TestHttp (0.00s)
    handle_test.go:46: 2
FAIL
FAIL	test_inline/test	0.003s
@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2018

@houxl123

This comment has been minimized.

Copy link
Author

commented Sep 17, 2018

@davecheney
I have already mentioned a new question.
#27708

@houxl123 houxl123 closed this Sep 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.