cmd/go: 'go test -gcflags=all=-l' appears not to disable inlining #27551
Comments
|
The command you quoted has several typos. Can you please tell us the precise command you used.
… On 7 Sep 2018, at 12:34, houxl123 ***@***.***> wrote:
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 tests-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 tests-gcflags =all=-l, it doesn't work to disable dependency package inlining in go1.11
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@davecheney Sorry, I have already modified it. |
|
Hi,
Thank you for providing an updated script to run.
I tried this on my local machine and was not able to replicate your results
go build -v ./some/path
then running
go build -gcflags=all=-l -v ./some/path
showed that the second command caused the entire project to be rebuilt,
including the standard library. Adding the -x flag to the command showed
that -l was being propagated down to the compiler,
/Users/dfc/go/pkg/tool/darwin_amd64/compile -o $WORK/b113/_pkg_.a -trimpath
$WORK/b113 -l -p vendor/golang_org/x/crypto/curve25519 -std -buildid
64qm83kR8j9I7NR-wJM4/64qm83kR8j9I7NR-wJM4 -D "" -importcfg
$WORK/b113/importcfg -pack -asmhdr $WORK/b113/go_asm.h -c=4 ./doc.go
./mont25519_amd64.go
cd $WORK/b063
Can I ask that you double check that you have Go 1.11 or later installed on
your machine and that `which go` is pointing to that version, not an
earlier installation.
…On 7 September 2018 at 15:47, houxl123 ***@***.***> wrote:
@davecheney <https://github.com/davecheney> Sorry, I have already
modified it.
go test -gcflags=all=-l
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27551 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA1wU0jNZKJLyUdNf9aX9VFUcYp0Qks5uYghzgaJpZM4WeFAJ>
.
|
|
@davecheney Thank you very much for your answer, from |
|
|
|
Can we step up a level, though? Why/how does the test require that inlining be disabled? The only visible difference should be in the behavior of |
bcmills
added
WaitingForInfo
bcmills
changed the title
Could you please provide some more detail? How did you determine whether the package or function in question was actually inlined? |
|
@bcmills Thank you very much for your answer, because I am sorry that I did not respond in time. I executed |
|
@davecheney @bcmills Thank you for your answer. After testing, |
|
@davecheney @bcmills Thank you very much for your previous answer, I found the reason for the problem, go1.11 version, |
|
Please use -gclfacgs="-l -m" to understand the compilers inlining decisions.
…On 17 September 2018 at 18:29, houxl123 ***@***.***> wrote:
Reopened #27551 <#27551>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27551 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAAcAytR68XAlMyE5RzCpHi1DTCGr5xBks5ub110gaJpZM4WeFAJ>
.
|
|
@davecheney |
|
This appears unrelated to the issue you raised. Please raise a new issue.
… On 17 Sep 2018, at 19:07, houxl123 ***@***.***> wrote:
@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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@davecheney |
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=-lin go1.10 disables inlining, but it does not work in go1.11If 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.11The text was updated successfully, but these errors were encountered: