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: -B on 32bit GOARCHs causes internal compiler error #48092

Closed
divVerent opened this issue Aug 31, 2021 · 6 comments
Closed

cmd/compile: -B on 32bit GOARCHs causes internal compiler error #48092

divVerent opened this issue Aug 31, 2021 · 6 comments

Comments

@divVerent
Copy link

@divVerent divVerent commented Aug 31, 2021

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

$ go version
go version go1.17 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="amd64"
GOBIN=""
GOCACHE="/home/rpolzer/.cache/go-build"
GOENV="/home/rpolzer/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/rpolzer/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rpolzer/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/rpolzer/homedir/src/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/rpolzer/homedir/src/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1448838183=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ cat > hello.go
package main

func main() {
}
^D
$ GOOS=windows GOARCH=386 go build -gcflags='all=-B' hello.go

What did you expect to see?

A Win32 PE EXE file that does nothing.

What did you see instead?

# internal/abi
/home/rpolzer/homedir/src/go/src/internal/abi/abi.go:52:30: internal compiler error: '(*IntArgRegBitmap).Get': not lowered: v16, Unknown UINT8

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

Note: without the -B flag, the issue does not occur. On linux/amd64 and windows/amd64 -B is fine to use and improves performance.

@ALTree ALTree changed the title -gcflags -B on Win32 causes internal error cmd/compile: -B on GOARCH=386 causes internal compiler error Aug 31, 2021
@ALTree
Copy link
Member

@ALTree ALTree commented Aug 31, 2021

It looks like the crash is triggered when compiling internal/abi:

$ GOARCH=386 go build -gcflags=-B internal/abi

# internal/abi
/usr/local/go/src/internal/abi/abi.go:42:29: internal compiler error: '(*IntArgRegBitmap).Set': not lowered: v14, Unknown UINT8

Tip also crashes. Other GOARCHs are also affected. Both arm and mipsle crash too.

cc @randall77 @mknyszek @aclements

Loading

@ALTree ALTree changed the title cmd/compile: -B on GOARCH=386 causes internal compiler error cmd/compile: -B on 32bit GOARCHs causes internal compiler error Aug 31, 2021
@ALTree ALTree added this to the Go1.18 milestone Aug 31, 2021
@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 31, 2021

This happens when we do:

type A [0]int
var a A
x := a[i]

The compiler uses an explicit "never use me" value for x, because it knows that the bounds check can never succeed, and thus the value of x must be on a dead path in the CFG. But then with -B, uses of x aren't on dead paths, and the compiler rightly complains it is trying to use a "never use me" value.

This happens in internal/abi for all the architectures that haven't been converted yet (everything except amd64 and arm64), because IntArgsReg is 0, and thus IntArgRegBitmap is [0]uint8.

It's not entirely clear to me that this is a bug worth fixing. -B is really a bleeding edge kind of request. Asserting to the compiler that all bounds checks will pass, while giving it code where the bounds check cannot possibly pass, is asking for trouble. That said, the fix is easy (use the zero value of x's type), and it's probably worth having the stdlib at least compile with -B, even if it would never run correctly like that.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 31, 2021

Change https://golang.org/cl/346589 mentions this issue: cmd/compile: use the zero value for results of impossible indexing

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 31, 2021

I don't think this is worth backporting, though. It's easy enough to work around by either not indexing 0-length arrays, or not using -B.

Loading

@gopherbot gopherbot closed this in 1f83a8c Aug 31, 2021
@divVerent
Copy link
Author

@divVerent divVerent commented Aug 31, 2021

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 31, 2021

-B isn't really intended to be used by anybody. When you use -B the compiler isn't adhering to the Go spec any more. It's intended just to be used for measuring the overhead of bounds checks. We've been discussing removing -B altogether.

Loading

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