Skip to content

cmd/gc: invalid race detector rewrite #7334

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

Closed
rsc opened this issue Feb 14, 2014 · 3 comments
Closed

cmd/gc: invalid race detector rewrite #7334

rsc opened this issue Feb 14, 2014 · 3 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Feb 14, 2014

The liveness analysis is about to get very picky about seeing variables used before they
are initialized. It has turned up the following problem in the generated race detector
code.

When I submit the liveness analysis changes, I will disable the race detector test in
run.bash, with a link to this issue.

package main

func f(x, y []byte) []byte {
    return append(x, y...)
}

If you run go tool 6g -W x.go, the output begins:

---
before f
.   RETURN l(4) tc(1)
.   RETURN-list
.   .   APPEND l(4) tc(1) isddd(1) ARRAY-[]byte
.   .   APPEND-list
.   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20) ld(1)
tc(1) used(1) ARRAY-[]byte

.   .   .   NAME-main.y u(1) a(1) g(3) l(3) x(24+0) class(PPARAM) f(1) esc(no) ld(1)
tc(1) used(1) ARRAY-[]byte
after walk f
.   RETURN-init
.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0000 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) ARRAY-[]byte
.   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20) ld(1)
tc(1) used(1) ARRAY-[]byte

.   .   IF-init
.   .   .   AS u(3) l(4) tc(1)
.   .   .   .   NAME-main.autotmp_0001 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) int
.   .   .   .   SUB u(3) l(4) tc(1) int
.   .   .   .   .   ADD u(3) l(4) tc(1) int
.   .   .   .   .   .   LEN u(2) l(4) tc(1) int
.   .   .   .   .   .   .   NAME-main.autotmp_0000 u(1) a(1) l(4) x(0+0) class(PAUTO)
esc(N) tc(1) used(1) ARRAY-[]byte
.   .   .   .   .   .   LEN u(2) l(4) tc(1) int
.   .   .   .   .   .   .   NAME-main.y u(1) a(1) g(3) l(3) x(24+0) class(PPARAM) f(1)
esc(no) ld(1) tc(1) used(1) ARRAY-[]byte
.   .   .   .   .   CAP u(2) l(4) tc(1) int
.   .   .   .   .   .   NAME-main.autotmp_0000 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N)
tc(1) used(1) ARRAY-[]byte

---

Note that the very first RETURN-init statement is the assignment of x to autotmp_0000.
Then some things in the IF-init refer to cap(autotmp_0000).

But if you say 6g -race -W x.go. the output begins:

---
before f
.   RETURN l(4) tc(1)
.   RETURN-list
.   .   APPEND l(4) tc(1) isddd(1) ARRAY-[]byte
.   .   APPEND-list
.   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20) ld(1)
tc(1) used(1) ARRAY-[]byte

.   .   .   NAME-main.y u(1) a(1) g(3) l(3) x(24+0) class(PPARAM) f(1) esc(no) ld(1)
tc(1) used(1) ARRAY-[]byte
after walk f
.   RETURN-init
.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0002 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) int
.   .   .   LEN u(2) l(4) tc(1) int
.   .   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20) ld(1)
tc(1) used(1) ARRAY-[]byte

.   .   AS u(3) l(4) tc(1)
.   .   .   NAME-main.autotmp_0003 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) int
.   .   .   ADD u(3) l(4) tc(1) int
.   .   .   .   LEN u(2) l(4) tc(1) int
.   .   .   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20)
ld(1) tc(1) used(1) ARRAY-[]byte
.   .   .   .   LEN u(2) l(4) tc(1) int
.   .   .   .   .   NAME-main.y u(1) a(1) g(3) l(3) x(24+0) class(PPARAM) f(1) esc(no)
ld(1) tc(1) used(1) ARRAY-[]byte

.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0004 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) uint64
.   .   .   CONV u(2) l(4) tc(1) uint64
.   .   .   .   CAP u(2) l(4) tc(1) int
.   .   .   .   .   NAME-main.autotmp_0000 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N)
tc(1) used(1) ARRAY-[]byte

.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0005 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) uint64
.   .   .   CONV u(2) l(4) tc(1) uint64
.   .   .   .   NAME-main.autotmp_0003 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) int

.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0006 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) uint64
.   .   .   CONV u(2) l(4) tc(1) uint64
.   .   .   .   NAME-main.autotmp_0002 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) int

.   .   AS u(2) l(4) tc(1)
.   .   .   NAME-main.autotmp_0000 u(1) a(1) l(4) x(0+0) class(PAUTO) esc(N) tc(1)
used(1) ARRAY-[]byte
.   .   .   NAME-main.x u(1) a(1) g(2) l(3) x(0+0) class(PPARAM) f(1) esc(20) ld(1)
tc(1) used(1) ARRAY-[]byte

---

The IF-init appears to have been hoisted up above the RETURN-init: the initialization of
autotmp_000 happens at the very bottom of the snippet, but there is a reference to
cap(autotmp_0000) in the middle of the snippet.

This is before racewalk even runs, but appendslice contains an if(flag_race) that
generates different code, code that appears to be buggy.

Release-Go1.3 because this makes the race detector unusable.
@minux
Copy link
Member

minux commented Feb 16, 2014

Comment 1:

Issue #7340 has been merged into this issue.

@remyoudompheng
Copy link
Contributor

Comment 2:

https://golang.org/cl/65740043
There is still another compilation issue which seems unrelated.
# reflect_test
pkg/reflect/all_test.go:1794: internal error: TestMethod5 autotmp_1942 (type Tm1)
recorded as live on entry
FAIL    reflect [build failed]

Status changed to Started.

@remyoudompheng
Copy link
Contributor

Comment 3:

This issue was closed by revision 475e7d0.

Status changed to Fixed.

@rsc rsc added fixed labels Feb 19, 2014
@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
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

4 participants