compile: add result in the infinite loop is wrong

[WangLeonard]

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

$ go version
go version devel go1.17-4a7effa418 Wed Apr 28 14:01:59 2021 +0000 darwin/amd64

Does this issue reproduce with the latest release?

yes

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/leonardwang/Library/Caches/go-build"
GOENV="/Users/leonardwang/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/leonardwang/Project/GOPATH/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/leonardwang/Project/GOPATH"
GOPRIVATE=""
GOPROXY="https://goproxy.io,direct"
GOROOT="/Users/leonardwang/Local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/leonardwang/Local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-4a7effa418 Wed Apr 28 14:01:59 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/leonardwang/Project/GOPATH/src/github.com/WangLeonard/gostudy/0419/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1z/j7mt1cf9537cnh20_8tj4n7m0000gn/T/go-build1160547914=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

import (
	"fmt"
	"time"
)

func main() {
	var x int64 = 0
	for i := 0; i < 20; i++ {
		go func() {
			for {
				x++
			}
		}()
	}
	time.Sleep(time.Second * 10)
	fmt.Println(x)
}

I know this example may not be appropriate, there is a data rece
But it always prints 0

go build -gcflags="-N -l -S -m=2" ./main.go

"".main.func1 STEXT nosplit size=8 args=0x8 locals=0x0 funcid=0x0
        0x0000 00000 (main.go:11)     TEXT    "".main.func1(SB), NOSPLIT|ABIInternal, $0-8
        0x0000 00000 (main.go:11)     FUNCDATA        $0, gclocals·2a5305abe05176240e61b8620e19a815(SB)
        0x0000 00000 (main.go:11)     FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (main.go:12)     JMP     2
        0x0002 00002 (main.go:14)     JMP     4
        0x0004 00004 (main.go:14)     JMP     6
        0x0006 00006 (main.go:14)     JMP     2

In the assembly code of go func,
It's just jmp, but no add.

I add some extra code to go func, such as print, or modifying it to atomic, it will not print 0 anymore.

What did you expect to see?

not 0

What did you see instead?

0

[ALTree]

A program with a data race in it is not a valid Go program and it could do anything. In this case, it look like the compiler decided that it is allowed to remove the writes to x, so the program will print 0. We usually don't consider this kind of issues (of a racy program) as bugs.

[WangLeonard]

In fact, it can be reproduced like this. Is this also considered to be a race?

func main() {
	var x int64 = 0
	go func() {
		for {
			x++
		}
	}()
	time.Sleep(time.Second * 1)
	fmt.Println(x)
}

[seankhliao]

@WangLeonard you may be interetested in https://blog.golang.org/race-detector

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[ALTree]

Anything that when run under go run -race test.go prints race detector warnings is almost surely a race. As @seankhliao pointed out, the race-detector post on the blog may be interesting to you.

[WangLeonard]

Anything that when run under go run -race test.go prints race detector warnings is almost surely a race. As @seankhliao pointed out, the race-detector post on the blog may be interesting to you.
Ok, after this example is modified, it is confirmed that data race still exists( use go run -race test.go).
Optimizing undefined behavior also looks fine.
Thank you. @ALTree @seankhliao

[ianlancetaylor]

If you are really interested in understanding the underlying formalism that explains what a race is in Go, see https://golang.org/ref/mem.