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

Jump to bottom

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

cmd/compile: internal compiler error: value v132 still has 1 uses when GOARCH=arm #48916

gz-95 opened this issue Oct 12, 2021 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.18

Comments

@gz-95
Copy link

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 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

@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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 12, 2021
@ALTree ALTree added this to the Go1.18 milestone Oct 12, 2021
@cuonglm
Copy link
Member

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

@ok-john
Copy link

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

@cuonglm
Copy link
Member

cuonglm commented Oct 12, 2021 •
edited

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

cc @dr2chase @cherrymui

@dr2chase
Copy link
Contributor

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

@dr2chase
Copy link
Contributor

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.

@cherrymui
Copy link
Member

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.

@randall77
Copy link
Contributor

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

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Oct 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
8 participants
@dr2chase @ALTree @cuonglm @randall77 @gopherbot @cherrymui @ok-john @gz-95