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/compile: internal compiler error: value v132 still has 1 uses when GOARCH=arm #48916

Closed
gz-95 opened this issue Oct 12, 2021 · 9 comments
Closed

Comments

@gz-95
Copy link

@gz-95 gz-95 commented Oct 12, 2021

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

$ go version
go version go1.17.2 linux/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=""
GOARCH="arm"
GOBIN="/home/.go/bin"
GOCACHE="/home/.cache/go-build"
GOENV="/home/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
GOARM="5"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3247440742=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ export GOARCH=arm
$ go build main.go

main.go is the following:

package main

func main() {
}

type dummy struct {
	num int64
}

func foo(vs map[dummy]struct{}, d dummy) error {
	_, ok := vs[d]
	if !ok {
		return nil
	}

	switch d.num {
	case 0:
	case 1:
	case 2:
	case 3:
	case 4:
	case 5:
	case 6:
		var num float64
		if num != 0 {
			return nil
		}
	}

	return nil
}

What did you expect to see?

Program compiled successfully.

What did you see instead?

# command-line-arguments
./main.go:12:2: internal compiler error: 'foo': value v132 still has 1 uses

Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new
@ALTree
Copy link
Member

@ALTree ALTree commented Oct 12, 2021

Mh, I can't reproduce this:

$ go version
go version go1.17.2 windows/amd64

$ export GOARCH=arm
$ go build test.go
# no error

cc @randall77

Loading

@ALTree ALTree changed the title internal compiler error: value v132 still has 1 uses when GOARCH=arm cmd/compile: internal compiler error: value v132 still has 1 uses when GOARCH=arm Oct 12, 2021
@ALTree ALTree added this to the Go1.18 milestone Oct 12, 2021
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Oct 12, 2021

I can reproduce this on darwin/arm64, both with 1.17 and tip:

$ GOARCH=arm go tool compile x.go
x.go:12:2: internal compiler error: 'foo': value v138 still has 1 uses

Loading

@ok-john
Copy link

@ok-john ok-john commented Oct 12, 2021

I can reproduce on linux/amd64:

$ go version
go version go1.17.2 linux/amd64

$ GOARCH=arm go build main.go
# command-line-arguments
./main.go:12:2: internal compiler error: 'foo': value v132 still has 1 uses

Loading

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Oct 12, 2021

Seems this happens on platform with reg abi supports. I bisected it to CL 293396.

cc @dr2chase @cherrymui

Loading

@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Oct 12, 2021

Has something to do with softfloat, also fails for

GOOS=linux GOARCH=mips GOMIPS=softfloat go build main.go

but not

GOOS=linux GOARCH=mips go build main.go

Loading

@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Oct 12, 2021

One good-looking fix is to run dead code after prove; dead stuff was fed to expand_calls, and that's not a good idea in general.

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Oct 12, 2021

Yeah, we probably could do that. I think there was another issue about dead values left over from prove.

On the other hand, expand_calls could probably be more resilient also. This particular problem seems that we invalided v138 in one iteration and then a later iteration generates a use v30 = Copy v138 from commonArgs map lookup. We should probably want to not generating such use if the value is dead already.

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 12, 2021

Here's a recent issue for which a deadcode pass after prove would help:
#48882 (comment)

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 12, 2021

Change https://golang.org/cl/355409 mentions this issue: cmd/compile: do not reuse dead value in expand_calls pass

Loading

@gopherbot gopherbot closed this in 6e0adde Oct 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants