cmd/compile: register ABI bringup testcase failures (tracking issue) #44816

thanm · 2021-03-05T17:32:29Z

Note: this is not a regular bug, but instead tracking issue in which to collect testcases that cause failures with the new Go register ABI work.

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

$ go version
go version devel +a2f7067233 Fri Mar 5 15:34:32 2021 +0000 linux/amd64

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

linux/amd64

What did you do?

First instance:

$ git clone https://github.com/thanm/cabi-testgen
...
$ cd cabi-testgen/cabi-testgen
$ git checkout 0779299
$ go build .
$ ./cabi-testgen -q 1 -n 1 -s 1614962541 -o /tmp/cabiTest -p cabiTest -pragma registerparams
$ cd  /tmp/cabiTest
$ go build -p 1 .

What did you expect to see?

clean build

What did you see instead?

testcase.go:37:6: internal compiler error: 'Test0': not lowered: v10, StringPtr PTR STRING

goroutine 19 [running]:
runtime/debug.Stack(0xf9ecc0, 0xc0000be008, 0x0)
	/w/go/src/runtime/debug/stack.go:24 +0x9f
cmd/compile/internal/base.FatalfAt(0x2506000000002, 0xc0004b1cc8, 0x8, 0xc0003ad880, 0x2, 0x2)
	/w/go/src/cmd/compile/internal/base/print.go:227 +0x1bc
cmd/compile/internal/base.Fatalf(...)
	/w/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc0003dd2f0, 0x2506000000002, 0xe4e7d2, 0x2, 0xc00009fcf0, 0x1, 0x1)
	/w/go/src/cmd/compile/internal/ssagen/ssa.go:7353 +0x1a7
cmd/compile/internal/ssa.(*Func).Fatalf(...)
	/w/go/src/cmd/compile/internal/ssa/func.go:656
cmd/compile/internal/ssa.checkLower(0xc00017dba0)
	/w/go/src/cmd/compile/internal/ssa/lower.go:41 +0x439
cmd/compile/internal/ssa.Compile(0xc00017dba0)
	/w/go/src/cmd/compile/internal/ssa/compile.go:96 +0x99e
cmd/compile/internal/ssagen.buildssa(0xc000100580, 0x0, 0x0)
	/w/go/src/cmd/compile/internal/ssagen/ssa.go:635 +0x18d2
cmd/compile/internal/ssagen.Compile(0xc000100580, 0x0)
	/w/go/src/cmd/compile/internal/ssagen/pgen.go:158 +0x5f
cmd/compile/internal/gc.compileFunctions.func2.1(0xc000124310, 0xc000100580, 0xc0000be700, 0xc0000bb5c0)
	/w/go/src/cmd/compile/internal/gc/compile.go:130 +0x65
created by cmd/compile/internal/gc.compileFunctions.func2
	/w/go/src/cmd/compile/internal/gc/compile.go:128 +0x8e

Reduced testcase attached, repro with "go tool compile -p x testcase.go".
testcase.go.txt

The text was updated successfully, but these errors were encountered:

thanm · 2021-03-05T17:33:18Z

@dr2chase, @aclements , @mknyszek , @cherrymui , @jeremyfaller

thanm · 2021-03-05T17:40:56Z

OK, here is a second problem (different failure mode). This is on the caller side (requires two packages).

Recipe:

$ git clone https://github.com/thanm/cabi-testgen
...
$ cd cabi-testgen/cabi-testgen
$ git checkout 0779299
$ go build .
$ ./cabi-testgen -q 1 -n 1 -s 2345 -o /tmp/cabiTest -p cabiTest -pragma registerparams
$ cd  /tmp/cabiTest
$ go build -p 1 .

Failure mode:

# cabiTest/genCaller0
genCaller0/genCaller0.go:43:9: internal compiler error: 'Caller0': panic during schedule while compiling Caller0:

runtime error: index out of range [10] with length 9

goroutine 8 [running]:
cmd/compile/internal/ssa.Compile.func1(0xc000558cf8, 0xc00007e340)
	/w/go/src/cmd/compile/internal/ssa/compile.go:48 +0xa5
panic(0xe105a0, 0xc0000e86c0)
	/w/go/src/runtime/panic.go:972 +0x1d4
cmd/compile/internal/ssa.schedule(0xc00007e340)
	/w/go/src/cmd/compile/internal/ssa/schedule.go:277 +0x235c
cmd/compile/internal/ssa.Compile(0xc00007e340)
	/w/go/src/cmd/compile/internal/ssa/compile.go:96 +0x99e
cmd/compile/internal/ssagen.buildssa(0xc0001022c0, 0x0, 0x0)
	/w/go/src/cmd/compile/internal/ssagen/ssa.go:635 +0x18d2
cmd/compile/internal/ssagen.Compile(0xc0001022c0, 0x0)
	/w/go/src/cmd/compile/internal/ssagen/pgen.go:158 +0x5f
cmd/compile/internal/gc.compileFunctions.func2.1(0xc0000b8000, 0xc0001022c0, 0xc0000be088, 0xc0000ba1a0)
	/w/go/src/cmd/compile/internal/gc/compile.go:130 +0x65
created by cmd/compile/internal/gc.compileFunctions.func2
	/w/go/src/cmd/compile/internal/gc/compile.go:128 +0x8e

To reproduce, download the cabiTest.zip file, then

$ unzip cabiTest.zip
$ cd cabiTest
$ go build -p 1 .

cabiTest.zip

mknyszek · 2021-03-05T19:01:07Z

The following program fails to compile at tip (with GOEXPERIMENT=regabi set during ./make.bash of course):

package main

import "fmt"

//go:registerparams
//go:noinline
func passStruct6(a Struct6) Struct6 {
        return a
}

type Struct6 struct {
        Struct1
}

type Struct1 struct {
        A, B, C uint
}

func main() {
        fmt.Println(passStruct6(Struct6{Struct1{1, 2, 3}}))
}

Output:

$ ~/toolchain/bin/go run error.go
# command-line-arguments
./error.go:8:2: internal compiler error: 'passStruct6': not lowered: v4, StructSelect UINT STRUCT

goroutine 14 [running]:
runtime/debug.Stack(0xf7e1e0, 0xc00000e018, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/runtime/debug/stack.go:24 +0x94
cmd/compile/internal/base.FatalfAt(0x802100000002, 0xc0005d3cc8, 0x8, 0xc0004812e0, 0x2, 0x2)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/base/print.go:227 +0x1ac
cmd/compile/internal/base.Fatalf(...)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc00010a3c0, 0x802100000002, 0xe2da72, 0x2, 0xc0000acf60, 0x1, 0x1)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/ssa.go:7353 +0x195
cmd/compile/internal/ssa.(*Func).Fatalf(...)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/func.go:656
cmd/compile/internal/ssa.checkLower(0xc0003f81a0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/lower.go:41 +0x3fa
cmd/compile/internal/ssa.Compile(0xc0003f81a0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/compile.go:96 +0x98d
cmd/compile/internal/ssagen.buildssa(0xc0003d4160, 0x0, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/ssa.go:635 +0x1892
cmd/compile/internal/ssagen.Compile(0xc0003d4160, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/pgen.go:158 +0x52
cmd/compile/internal/gc.compileFunctions.func2.1(0xc0003f0080, 0xc0003d4160, 0xc0000a24e8, 0xc0003dd010)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:130 +0x56
created by cmd/compile/internal/gc.compileFunctions.func2
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:128 +0x85

mknyszek · 2021-03-05T19:15:03Z

Another ICE at tip:

package main

import "fmt"

//go:registerparams
//go:noinline
func passStruct8(a Struct8) Struct8 {
        return a
}

type Struct8 struct {
        Struct5
        Struct1
}

type Struct1 struct {
        A, B, C uint
}

type Struct5 struct {
        A             uint16
        B             int16
        C, D          uint32
        E             int32
        F, G, H, I, J float32
}

func main() {
        fmt.Println(passStruct8(Struct8{
                Struct5{1, 2, 3, 4, 5, 1.0, 2.0, 3.0, 4.0, 5.0},
                Struct1{1, 2, 3},
        }))
}

Output:

# command-line-arguments                                                                                                                                                                                    
./error2.go:33:1: internal compiler error: 'main': panic during regalloc while compiling main:                                                                                                              
                                                                                                                                                                                                            
nil v, s.orig[8], vi = {0 <nil> 0xc0006d0518 2 5 false false}, spill = v103 = StoreReg <mem>                                                                                                                
                                                                                                                                                                                                            
goroutine 9 [running]:                        
cmd/compile/internal/ssa.Compile.func1(0xc0004bccf8, 0xc0000a4000)                                 
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/compile.go:48 +0x9c
panic(0xd9d380, 0xc000068330)                                                                         
        /usr/local/google/home/mknyszek/toolchain/src/runtime/panic.go:972 +0x1c5
cmd/compile/internal/ssa.(*regAllocState).placeSpills(0xc000082480)                                
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:1816 +0xed8  
cmd/compile/internal/ssa.(*regAllocState).regalloc(0xc000082480, 0xc0000a4000)                    
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:1730 +0x73e6
cmd/compile/internal/ssa.regalloc(0xc0000a4000)                                                       
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:147 +0x5d
cmd/compile/internal/ssa.Compile(0xc0000a4000)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/compile.go:96 +0x98d
cmd/compile/internal/ssagen.buildssa(0xc0001042c0, 0x1, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/ssa.go:635 +0x1892
cmd/compile/internal/ssagen.Compile(0xc0001042c0, 0x1)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/pgen.go:158 +0x52
cmd/compile/internal/gc.compileFunctions.func2.1(0xc000030100, 0xc0001042c0, 0xc0000ba700, 0xc0000b72b0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:130 +0x56
created by cmd/compile/internal/gc.compileFunctions.func2
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:128 +0x85



goroutine 9 [running]:
runtime/debug.Stack(0xf7e1e0, 0xc0000ba008, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/runtime/debug/stack.go:24 +0x94
cmd/compile/internal/base.FatalfAt(0x2101000000002, 0xc00043a3c0, 0x32, 0xc000490500, 0x5, 0x5)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/base/print.go:227 +0x1ac
cmd/compile/internal/base.Fatalf(...)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc00061c600, 0x2101000000002, 0xe55822, 0x2c, 0xc000420740, 0x4, 0x4)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/ssa.go:7353 +0x195
cmd/compile/internal/ssa.(*Func).Fatalf(...)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/func.go:656
cmd/compile/internal/ssa.Compile.func1(0xc0004bccf8, 0xc0000a4000)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/compile.go:53 +0x225
panic(0xd9d380, 0xc000068330)
        /usr/local/google/home/mknyszek/toolchain/src/runtime/panic.go:972 +0x1c5
cmd/compile/internal/ssa.(*regAllocState).placeSpills(0xc000082480)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:1816 +0xed8 
cmd/compile/internal/ssa.(*regAllocState).regalloc(0xc000082480, 0xc0000a4000)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:1730 +0x73e6
cmd/compile/internal/ssa.regalloc(0xc0000a4000)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/regalloc.go:147 +0x5d
cmd/compile/internal/ssa.Compile(0xc0000a4000)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssa/compile.go:96 +0x98d
cmd/compile/internal/ssagen.buildssa(0xc0001042c0, 0x1, 0x0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/ssa.go:635 +0x1892
cmd/compile/internal/ssagen.Compile(0xc0001042c0, 0x1)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/ssagen/pgen.go:158 +0x52
cmd/compile/internal/gc.compileFunctions.func2.1(0xc000030100, 0xc0001042c0, 0xc0000ba700, 0xc0000b72b0)
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:130 +0x56
created by cmd/compile/internal/gc.compileFunctions.func2
        /usr/local/google/home/mknyszek/toolchain/src/cmd/compile/internal/gc/compile.go:128 +0x85

mknyszek · 2021-03-05T21:13:50Z

I don't know what I changed, but now when I run that last test case I get

tmp $ ~/toolchain/bin/go run error2.go
# command-line-arguments
<autogenerated>:1: invalid instruction: 00022 (/usr/local/google/home/mknyszek/tmp/error2.go:7) MOVUPS  R8, X5
<autogenerated>:1: invalid instruction: 00028 (/usr/local/google/home/mknyszek/tmp/error2.go:7) MOVUPS  R9, X5
<autogenerated>:1: invalid instruction: 00034 (/usr/local/google/home/mknyszek/tmp/error2.go:7) MOVUPS  R10, X5
<autogenerated>:1: invalid instruction: 00228 (/usr/local/google/home/mknyszek/tmp/error2.go:8) MOVUPS  X5, R8
<autogenerated>:1: invalid instruction: 00228 (/usr/local/google/home/mknyszek/tmp/error2.go:8) MOVUPS  X6, R9
<autogenerated>:1: invalid instruction: 00228 (/usr/local/google/home/mknyszek/tmp/error2.go:8) MOVUPS  X7, R10

gopherbot · 2021-03-06T01:00:18Z

Change https://golang.org/cl/299389 mentions this issue: cmd/compile: fix OpArg decomposer for registers in expandCalls

dr2chase · 2021-03-06T02:07:08Z

@mknyszek
Welcome to the land of concurrent compilation, it seemed like a good idea at the time. Your test shows two bugs.
Try

GOMAXPROCS=1 GOSSADIR=`pwd` GOSSAFUNC=passStruct8 go build -p 1 -gcflags='-c=1' mk.go

to see one of them more repeatably.

gopherbot · 2021-03-06T02:50:06Z

Change https://golang.org/cl/299409 mentions this issue: cmd/compile: fix broken type+offset calc for register args

gopherbot · 2021-03-07T15:40:42Z

Change https://golang.org/cl/299549 mentions this issue: cmd/compile: fix confusion in generating SelectN index

dr2chase · 2021-03-07T15:54:13Z

Smaller (edited) reproducer of the "invalid instruction" failures:

package main

import "fmt"

type P struct {
        a int8
        x float64
}

type T struct {
        d,e P
}

//go:registerparams
//go:noinline
func G(t T) float64 {
        return float64(t.d.a + t.e.a)+t.d.x+t.e.x
}

func main() {
        fmt.Println(G(T{P{10,20},P{30,40}}))
}

yields

go build mk.go
# command-line-arguments
<autogenerated>:1: cursym="".main, invalid instruction: 00034 (/Users/drchase/work/tmp/abi/mk.go:22)	MOVSD	$f64.4034000000000000(SB), BX
<autogenerated>:1: cursym="".main, invalid instruction: 00034 (/Users/drchase/work/tmp/abi/mk.go:22)	MOVL	$30, X0
<autogenerated>:1: cursym="".G, invalid instruction: 00017 (/Users/drchase/work/tmp/abi/mk.go:17)	MOVUPS	BX, X2

Says "autogenerated", but appears in the compilation output (v8), must be an artifact of the assembler reporting. I modified the diagnostic printer to be clear about what's being compiled.

# /Users/drchase/work/tmp/abi/mk.go
	00000 (16) TEXT "".G(SB), ABIInternal
	00001 (16) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	00002 (16) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
v7	00003 (+17) MOVL X0, CX
v13	00004 (17) ADDL CX, AX
v14	00005 (17) MOVBQSX AX, AX
v15	00006 (17) XORPS X0, X0
v15	00007 (17) CVTSL2SD AX, X0
v8	00008 (17) MOVUPS BX, X2
v18	00009 (17) ADDSD X2, X0
v21	00010 (17) ADDSD X1, X0
b1	00011 (17) RET
	00012 (?) END

dr2chase · 2021-03-07T18:16:02Z

Found it. I thought that abiutils would render the parameter registers I0, F0, I1, F1 -- in the order that the parameters use them -- and instead it does them I0, I1, F0, F1. Oops.

gopherbot · 2021-03-07T19:37:13Z

Change https://golang.org/cl/299570 mentions this issue: cmd/compile: fix failure to communicate between ABIinfo producer&consumer

gopherbot · 2021-03-08T23:29:46Z

Change https://golang.org/cl/299410 mentions this issue: cmd/compile: test register ABI for method, interface, closure calls

Includes test taken from #44816 (comment) and improved debugging output. Updates #44816 Change-Id: I94aeb9c5255f175fe80727be29d218bad54bf7ea Reviewed-on: https://go-review.googlesource.com/c/go/+/299389 Trust: David Chase <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

Includes more enhancements to debugging output. Updates #44816. Change-Id: I5b21815cf37ed21e7dec6c06f538090f32260203 Reviewed-on: https://go-review.googlesource.com/c/go/+/299409 Trust: David Chase <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

Old: return the ABI register index of the result (wrong!) New: return the index w/in sequence of result registers (right!) Fixed bug: genCaller0/genCaller0.go:43:9: internal compiler error: 'Caller0': panic during schedule while compiling Caller0: runtime error: index out of range [10] with length 9 Updates #44816. Change-Id: I1111e283658a2d6422986ae3d61bd95d1b9bde5e Reviewed-on: https://go-review.googlesource.com/c/go/+/299549 Trust: David Chase <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

…umer ABI info producer and consumer had different ideas for register order for parameters. Includes a test, includes improvements to debugging output. Updates #44816. Change-Id: I4812976f7a6c08d6fc02aac1ec0544b1f141cca6 Reviewed-on: https://go-review.googlesource.com/c/go/+/299570 Trust: David Chase <[email protected]> Reviewed-by: Than McIntosh <[email protected]>

gopherbot · 2021-03-11T01:57:25Z

Change https://golang.org/cl/300749 mentions this issue: cmd/compile: attempt to get spills right for output params in registers

gopherbot · 2021-03-12T17:13:49Z

Change https://golang.org/cl/300150 mentions this issue: cmd/compile: set unsayable "names" for regabi testing triggers

gopherbot · 2021-03-12T17:13:50Z

Change https://golang.org/cl/301270 mentions this issue: cmd/compile: minor cleanup -- remove dead code conditional on test

This is enabled with a ridiculous magic name for method, or for last input type passed, that needs to be changed to something inutterable before actual release. Ridiculous method name: MagicMethodNameForTestingRegisterABI Ridiculous last (input) type name: MagicLastTypeNameForTestingRegisterABI RLTN is tested with strings.Contains, so you can have MagicLastTypeNameForTestingRegisterABI1 and MagicLastTypeNameForTestingRegisterABI2 if that is helpful Includes test test/abi/fibish2.go Updates #44816. Change-Id: I592a6edc71ca9bebdd1d00e24edee1ceebb3e43f Reviewed-on: https://go-review.googlesource.com/c/go/+/299410 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

It would fail now if it were turned on. Updsates #44816. Change-Id: I19d94f0cb2dd84271f5304c796d7c81e1e64af25 Reviewed-on: https://go-review.googlesource.com/c/go/+/301270 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

ALSO: found evidence that stack maps for bodyless methods are wrong. gofmt in test/abi removed never-executed code in types/size.go Updates #44816. Change-Id: I658c33f049337fb6f1e625f0c55430d25bfa877e Reviewed-on: https://go-review.googlesource.com/c/go/+/300749 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

gopherbot · 2021-03-16T00:06:10Z

Change https://golang.org/cl/302071 mentions this issue: cmd/compile: (fixed) spill output parameters passed in registers as autos

gopherbot · 2021-03-16T16:21:26Z

Change https://golang.org/cl/302249 mentions this issue: cmd/compile: fix open defer of method call

dr2chase · 2021-03-16T16:33:33Z

Cleanup tasks once the rubble stops bouncing:

Prune fields out of AuxCall -- I put a lot of stuff in for transition purposes that is redundant w/ the ABI, the ABI is better.
Rationalize use of LocalsOffset() -- that's the thing that is non-zero if there's a link register, and getting that right has been a source of bugs and builder-breakage.
Restructure "parameters" to not be fields?

Somewhere in here I think we need to sync w/ the generics effort -- I am a little curious what happens to things like "Size" and "Offset" down the road. Conceivably, they will become expressions, that will be a minor party. If first effort is all templates, that won't happen immediately, but we might want to plan ahead.

…utos Repair of CL 300749. ALSO: found evidence that stack maps for bodyless methods are wrong. gofmt in test/abi removed never-executed code in types/size.go Updates #44816. Updates #40724. Change-Id: Ifeb5fee60f60e7c7b58ee0457f58a3265d6cf3f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/302071 Trust: David Chase <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

Code generation for open defers failed to account for presence of method receiver and thus was OFF BY ONE. Fixes #45062. Updates #44816. Updates #40724. Change-Id: Ia90ea8fd0f7d823e1f757c406f9127136c2ffdd2 Reviewed-on: https://go-review.googlesource.com/c/go/+/302249 Trust: David Chase <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

gopherbot · 2021-03-24T00:13:33Z

Change https://golang.org/cl/304233 mentions this issue: cmd/compile: fix array case in types-for-register parameter

Corrected typo/thinko. We should keep the test for this, but it doesn't run yet because of reflection as far as I know (but I am not testing w/ GOEXPERIMENT). See #44816 (comment) Updates #40724 Updates #44816 Change-Id: Ia12d0d4db00a8ec7174e72de460173876bd17874 Reviewed-on: https://go-review.googlesource.com/c/go/+/304233 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

thanm · 2021-03-25T14:53:48Z

Another test case from the fuzzer that causes a runtime error with regiabi (plus pragma).
testcase0325.zip

Symptom:

$ go run .
starting main
Error: fail |0|0| on =genChecker0.Test0= parm 1 elem 2
Error: fail |0|0| =genChecker0.Test0= reflect return 0
Error: fail |0|0| =genChecker0.Test0= reflect return 1
Error: fail |0|0| =genChecker0.Test0= reflect return 2
FAILURES: 4
exit status 2

thanm · 2021-03-25T16:28:37Z

Another test case from the fuzzer that causes a runtime error with regiabi (plus pragma). This is in the regular call path, not reflect.
testcase0325second.zip

Symptom:

$ go run .
starting main
Error: fail  |0|3| =genChecker0.Test3= parm 0 elem 0
FAILURES: 1
exit status 2

I eyeballed it in the debugger. Looks like RAX is being clobbered in the prolog before it can be used, or something along those lines.

dr2chase · 2021-03-25T16:46:30Z

Ugh, "works for me".

gopherbot · 2021-03-30T22:45:49Z

Change https://golang.org/cl/306109 mentions this issue: reflect: undo register count increments on register assignment failure

thanm · 2021-03-31T00:21:49Z

Another day, another new fuzzer failure. This one is pretty similar to the most recent one.
testcase0330.zip

From the SSA dump of the test function prolog:

b1:-
v1 (?) = InitMem <mem>
v2 (?) = SP <uintptr>
v3 (?) = SB <uintptr>
v23 (+54) = ArgIntReg <unsafe.Pointer> {p3+0} [3]
v26 (54) = ArgIntReg <uintptr> {p3+8} [4]
v29 (54) = ArgIntReg <unsafe.Pointer> {p3+16} [5]
v32 (54) = ArgIntReg <uintptr> {p3+24} [6]
v35 (54) = ArgIntReg <uint32> {p3+32} [7]
v40 (54) = Arg <int64> {p10} (p10[int64])
v52 (?) = MOVSDconst <float64> [0]
v61 (56) = LEAQ <*[256]uint64> {pad} v2
v88 (+67) = ArgIntReg <int> {p0+8} [1] (p0+8[int])
v2067 (67) = CMPQconst <flags> [16] v88
v2075 (54) = LEAQ <*StructF0S2> {r2} [24] v2
v2078 (54) = LEAQ <*StructF0S2> {r2} [40] v2
v8 (?) = LEAQ <*uint8> {go.string."genChecker0"} v3
v4 (?) = LEAQ <*uint8> {go.string."parm"} v3
v2179 (54) = MOVQstore <mem> {p3} v2 v23 v1
v2180 (54) = MOVQstore <mem> {p3} [8] v2 v26 v2179
v2181 (54) = MOVQstore <mem> {p3} [16] v2 v29 v2180
v2182 (54) = MOVQstore <mem> {p3} [24] v2 v32 v2181
v2183 (54) = MOVLstore <mem> {p3} [32] v2 v35 v2182
v2475 (222) = ArgFloatReg <float64> {p4+0} [0]
v2482 (222) = ArgIntReg <int8> {p6+0} [8]
v2506 (222) = ArgIntReg <unsafe.Pointer> {p0+0} [0]
v2508 (222) = ArgIntReg <uintptr> {p0+8} [1]
v2511 (222) = ArgIntReg <int64> {p2+0} [2]

So basically a bunch of Arg*Reg ops, then some other code, then more Arg*Reg ops. This is problematic; since regalloc can't see the later Arg*Reg ops, it will assign live param registers to the intervening code.

thanm · 2021-03-31T18:59:24Z

Another new failure. Zip file with contents:
testcase0330second.zip

Here it looks as though something is going wonky with respect to params that have to be spilled to the stack (since they are address taken).

Signature:

func Test1(p0 int8, p1 StructF1S0, p2 complex64, p3 complex64, _ *float64, p5 float32) (r0 StructF1S5, r1 ArrayF1S0E2, r2 int8, r3 int64, r4 float64) {

Here's what StructF1S0 looks like (expanded nested structs to improve readability):

type StructF1S0 struct {
F0 *string
F1 int64
F20 uint64
F21 int16
F3 float32
}

Checking code:

  ap1 := &p1
  ...
  p1f4c := StructF1S3{F0: StructF1S4{F0: float32(-1.4203252e+37)}}
  if deref_1(ap1).F3 != p1f4c {
    genUtils.NoteFailureElem(18, 9, 1, "genChecker9", "parm", 1, 4, false, pad[0])
    return
  }

In the prolog of the function when we spill p1 (since it is address taken), the code looks like

00008 (40) MOVQ BX, "".p1+16(SP)
00009 (40) MOVQ CX, "".p1+24(SP)
00010 (40) MOVQ DI, "".p1+32(SP)
00011 (40) MOVW SI, "".p1+40(SP)
00012 (40) MOVSS X0, "".p1+44(SP)

Seems ok. The checking code looks like

00079 (+78) LEAQ "".p1+16(SP), AX
00080 (78) MOVQ AX, (SP)
00081 (+78) PCDATA $1, $1
00082 (+78) CALL "".deref_1(SB)
00083 (78) MOVQ 8(SP), AX
00084 (78) MOVQ AX, ""..autotmp_29-88(SP)
00085 (78) MOVUPS 16(SP), X0
00086 (78) MOVUPS X0, ""..autotmp_29-80(SP)
00087 (78) MOVUPS 32(SP), X0
00088 (78) MOVUPS X0, ""..autotmp_29-64(SP)
00089 (78) MOVSS ""..autotmp_29-56(SP), X0
00090 (78) MOVSS $(-1.4203251708691171e+37), X1
00091 (78) UCOMISS X1, X0
00092 (78) JNE 207

The UCOMISS at 00091 is pick up the wrong value. So somewhere along the line (either spilling p1 or materializing its spill address) we got something wrong.

thanm · 2021-04-01T01:19:18Z

One last fuzzer failure for the day. Haven't analyzed it at all, but here it is.
testcase0330third.zip

Currently when register assignment fails we roll back all the abiParts that were generated in the process. However, the total number of registers also increases, but does not get rolled back. The result is a very incorrect register assignment. For #40724. For #44816. Change-Id: I1934ea5f95f7608ff2067166255099dbc9135e8c Reviewed-on: https://go-review.googlesource.com/c/go/+/306109 Trust: Michael Knyszek <[email protected]> Run-TryBot: Michael Knyszek <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Austin Clements <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

thanm · 2021-04-02T17:58:47Z

Switching back to reflect testing now that the regular call path seems clean. Here is a reduced testcase that shows a reflect.Call failure:
testcase0402second.zip

gopherbot · 2021-04-02T19:03:50Z

Change https://golang.org/cl/306929 mentions this issue: reflect: remove short-circuits for zero-sized types in ABI algorithm

This change removes two short-circuits for zero-sized types (zero-sized structs and zero-sized struct fields) in the recursive cases of the ABI algorithm, because this does not match the spec's algorithm, nor the compiler's algorithm. The failing case here is a struct with a field that is an array of non-zero length but whose element type is zero-sized. This struct must be stack-assigned because of the array, according to the algorithm. The reflect package was register-assigning it. Because there were two short-circuits, this can also appear if a struct has a field that is a zero-sized struct but contains such an array, also. This change adds regression tests for both of these cases. For #44816. For #40724. Change-Id: I956804170962448197a1c9853826e3436fc8b1ea Reviewed-on: https://go-review.googlesource.com/c/go/+/306929 Trust: Michael Knyszek <[email protected]> Run-TryBot: Michael Knyszek <[email protected]> Reviewed-by: Than McIntosh <[email protected]> Reviewed-by: Cherry Zhang <[email protected]> TryBot-Result: Go Bot <[email protected]>

thanm · 2021-04-07T14:51:32Z

Another reflect test cast that the fuzzer found a failure in:
testcase0407.zip

To reproduce, unpack the zip file and then:

$ cd cabiTest
GOEXPERIMENT=regabi,regabireflect,regabiargs go run .
$ starting main
Error: fail reflect |9|71|19| =genChecker71.Test19= parm 0 elem 1
FAILURES: 1
exit status 2
$

I should also add that in my repo I have this diff:

$ git diff
diff --git a/src/reflect/regabiargs_off.go b/src/reflect/regabiargs_off.go
index 655e955474..5dc4a063e4 100644
--- a/src/reflect/regabiargs_off.go
+++ b/src/reflect/regabiargs_off.go
@@ -7,4 +7,4 @@
 
 package reflect
 
-const experimentRegabiArgs = 0
+const experimentRegabiArgs = 1

This is a method call, not a regular call. In addition there seem to be a number of other moving parts (the param in question is address taken and escapes to the heap). It is a value receiver (not pointer), and the size of the type in question is zero. I shoudl also add that it looks as though there is a method wrapper involved (from the stack trace). Here is a dump of the abi regs at the point where the regular (non-reflect) call takes place, when we've just entered the Test19 function:

(gdb) showabiregs
"0: rax "$35 = 27
"1: rbx "$36 = 9887
"2: rcx "$37 = 0
"3: rdi "$38 = 11297
"4: rsi "$39 = 824633786928
"5: r8 "$40 = 2588397972534514886
"6: r9 "$41 = 8
"7: r10 "$42 = 140737353884592
"8: r11 "$43 = 824633786928
(gdb)

and here is the dump for the reflect call

(gdb) showabiregs
"0: rax "$44 = 27
"1: rbx "$45 = 0
"2: rcx "$46 = 0
"3: rdi "$47 = 11297
"4: rsi "$48 = 824633786928
"5: r8 "$49 = 2588397972534514886
"6: r9 "$50 = 2588397972534514886
"7: r10 "$51 = 0
"8: r11 "$52 = 0
(gdb)

So $rbx doesn't look right.

thanm · 2021-04-07T20:58:50Z

New fuzzer failure (compile time crash). Zip file with repro:
testcase0407second.zip

To reproduce, do:

$ unzip ...
$ cd cabiTest
$ GOEXPERIMENT=regabi,regabiargs go build  .
# cabiTest/genCaller42
genCaller42/genCaller42.go:166:35: internal compiler error: 'Caller2': panic during expand calls while compiling Caller2:

Unexpected selector of memory

goroutine 136 [running]:
cmd/compile/internal/ssa.Compile.func1()
	/ssd2/go/src/cmd/compile/internal/ssa/compile.go:48 +0xa5
panic(0xd85e60, 0xf7da28)
	/ssd2/go/src/runtime/panic.go:1031 +0x21f
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011b00f0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:399 +0x1dc6
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011a3f20, 0x0, 0xe36f00, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:469 +0x10de
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011b0940, 0x0, 0x0, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:483 +0x11ee
cmd/compile/internal/ssa.expandCalls(0xc00012a000)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:1357 +0x145d
cmd/compile/internal/ssa.Compile(0xc00012a000)
	/ssd2/go/src/cmd/compile/internal/ssa/compile.go:96 +0xc38
cmd/compile/internal/ssagen.buildssa(0xc000262580, 0x2, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssagen/ssa.go:642 +0x23c5
cmd/compile/internal/ssagen.Compile(0xc000262580, 0x2)
	/ssd2/go/src/cmd/compile/internal/ssagen/pgen.go:151 +0x58
cmd/compile/internal/gc.compileFunctions.func2.1()
	/ssd2/go/src/cmd/compile/internal/gc/compile.go:130 +0x75
created by cmd/compile/internal/gc.compileFunctions.func2
	/ssd2/go/src/cmd/compile/internal/gc/compile.go:128 +0xe5



goroutine 136 [running]:
runtime/debug.Stack(0xf8b2c0, 0xc000202008, 0x0)
	/ssd2/go/src/runtime/debug/stack.go:24 +0x94
cmd/compile/internal/base.FatalfAt(0xa623000000002, 0xc000a46340, 0x32, 0xc002f8de00, 0x5, 0x5)
	/ssd2/go/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
	/ssd2/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc000128000, 0xa623000000002, 0xe5d83a, 0x2c, 0xc002fa0340, 0x4, 0x4)
	/ssd2/go/src/cmd/compile/internal/ssagen/ssa.go:7383 +0x1ed
cmd/compile/internal/ssa.(*Func).Fatalf(0xc00012a000, 0xe5d83a, 0x2c, 0xc002fa0340, 0x4, 0x4)
	/ssd2/go/src/cmd/compile/internal/ssa/func.go:667 +0x327
cmd/compile/internal/ssa.Compile.func1()
	/ssd2/go/src/cmd/compile/internal/ssa/compile.go:53 +0x230
panic(0xd85e60, 0xf7da28)
	/ssd2/go/src/runtime/panic.go:1031 +0x21f
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011b00f0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:399 +0x1dc6
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011a3f20, 0x0, 0xe36f00, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:469 +0x10de
cmd/compile/internal/ssa.(*expandState).rewriteSelect(0xc00017bce0, 0xc0011b0940, 0xc0011b0940, 0x0, 0x0, 0x0, 0x0, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:483 +0x11ee
cmd/compile/internal/ssa.expandCalls(0xc00012a000)
	/ssd2/go/src/cmd/compile/internal/ssa/expand_calls.go:1357 +0x145d
cmd/compile/internal/ssa.Compile(0xc00012a000)
	/ssd2/go/src/cmd/compile/internal/ssa/compile.go:96 +0xc38
cmd/compile/internal/ssagen.buildssa(0xc000262580, 0x2, 0x0)
	/ssd2/go/src/cmd/compile/internal/ssagen/ssa.go:642 +0x23c5
cmd/compile/internal/ssagen.Compile(0xc000262580, 0x2)
	/ssd2/go/src/cmd/compile/internal/ssagen/pgen.go:151 +0x58
cmd/compile/internal/gc.compileFunctions.func2.1()
	/ssd2/go/src/cmd/compile/internal/gc/compile.go:130 +0x75
created by cmd/compile/internal/gc.compileFunctions.func2
	/ssd2/go/src/cmd/compile/internal/gc/compile.go:128 +0xe5

gopherbot · 2021-04-08T02:33:33Z

Change https://golang.org/cl/308309 mentions this issue: cmd/compile: sanitize before/after expansion OpSelectN references

In expand_calls, OpSelectN occurs both before and after the rewriting. Attempting to rewrite a post-expansion OpSelectN is bad. (The only ones rewritten in place are the ones returning mem; others are synthesized to replace other selection chains with register references.) Updates #40724. Updates #44816#issuecomment-815258897. Change-Id: I7b6022cfb47f808d3ce6cc796c067245f36047f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/308309 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> Reviewed-by: Than McIntosh <[email protected]>

gopherbot · 2021-04-08T16:49:32Z

Change https://golang.org/cl/308589 mentions this issue: cmd/compile: add recursive-invalidate Value method, use in expand_calls

thanm · 2021-04-08T18:00:07Z

Another reflect problem:
testcase0408.zip

This one seems to have to do with floating point values. Repro:

$ unzip testcase0408.zip
...
$ cd cabiTest
GOEXPERIMENT=regabi,regabireflect,regabiargs go run .
starting main
Error: fail reflect |10|73|5| =genChecker73.Test5= parm 5 elem 0
FAILURES: 1
exit status 2
$

Looking at the element in question ("p5"), on the calling side it is set up with

p5 = genChecker73.StructF5S2{F0: genChecker73.ArrayF5S0E0{}, F1: float32(-1.1470688e+37)}

If I stop at the entry point of genChecker73.Test5 and look at the floating point regs after the regular direct call, I see:

(gdb) p /x $xmm0.uint128
$32 = 0xbfeb8263537523d6
(gdb) p /x $xmm1.uint128
$33 = 0x3ffca0716ee47b6c
(gdb) p /x $xmm2.uint128
$34 = 0xfd0a12c9
(gdb)

For the reflect call, here's what's coming through:

(gdb) p /x $xmm0.uint128
$35 = 0xbfeb8263537523d6
(gdb) p /x $xmm1.uint128
$36 = 0x3ffca0716ee47b6c
(gdb) p /x $xmm2.uint128
$37 = 0x490ee0
(gdb)

So you can see that the value of $xmm2 doesn't look right.

This removes more unused values during transformation. Leaving them in the tree can create type conflicts in OpArg* references. Updates #40724. Updates #44816. Fixes #45417. Change-Id: I07dcb7b4b2bf8d79e22e0543cb2fb52c2ececb96 Reviewed-on: https://go-review.googlesource.com/c/go/+/308589 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Than McIntosh <[email protected]>

thanm · 2021-04-08T23:48:18Z

... and one more fuzzer-generated failure, also in reflect. Zip file:
testcase0408second.zip

This one is interesting in that the parameter in question isn't actually assigned to a register (as far as I can tell), it's passed on the stack. Haven't done any additional analysis.

Repro:

$ unzip testcase0408second.zip
...
$ cd cabiTest
$ GOEXPERIMENT=regabi,regabireflect,regabiargs go run . )
starting main
Error: fail reflect |31|99|13| =genChecker99.Test13= parm 6 elem 0
FAILURES: 1
exit status 2
$

This disables the "testing names" for method names and trailing input types passed to closure/interface/other calls. The logic using the names remains, so that editing the change to enable local testing is not too hard. Also fixes broken build tag in reflect/abi_test.go Updates #44816. Change-Id: I3d222d2473c98d04ab6f1122ede9fea70c994af1 Reviewed-on: https://go-review.googlesource.com/c/go/+/300150 Trust: David Chase <[email protected]> Run-TryBot: David Chase <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>

thanm self-assigned this Mar 5, 2021

ALTree changed the title ~~register ABI bringup testcase failures (tracking issue)~~ cmd/compile: register ABI bringup testcase failures (tracking issue) Mar 5, 2021

johejo mentioned this issue Apr 7, 2021

cmd/compile: failed to build google.golang.org/protobuf using regabi by internal compiler error #45417

Closed

rsc unassigned thanm Jun 23, 2022

cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 23, 2022

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022

mknyszek added this to Go Compiler / Runtime Jul 13, 2022

mknyszek moved this to Triage Backlog in Go Compiler / Runtime Jul 15, 2022

seankhliao added the umbrella label Aug 20, 2022

seankhliao added this to the Backlog milestone Aug 20, 2022

cmd/compile: register ABI bringup testcase failures (tracking issue) #44816

cmd/compile: register ABI bringup testcase failures (tracking issue) #44816

Comments

thanm commented Mar 5, 2021

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

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

What did you do?

What did you expect to see?

What did you see instead?

thanm commented Mar 5, 2021

thanm commented Mar 5, 2021

mknyszek commented Mar 5, 2021

mknyszek commented Mar 5, 2021

mknyszek commented Mar 5, 2021

gopherbot commented Mar 6, 2021

dr2chase commented Mar 6, 2021

gopherbot commented Mar 6, 2021

gopherbot commented Mar 7, 2021

dr2chase commented Mar 7, 2021 • edited Loading

dr2chase commented Mar 7, 2021

gopherbot commented Mar 7, 2021

gopherbot commented Mar 8, 2021

gopherbot commented Mar 11, 2021

gopherbot commented Mar 12, 2021

gopherbot commented Mar 12, 2021

gopherbot commented Mar 16, 2021

gopherbot commented Mar 16, 2021

dr2chase commented Mar 16, 2021

gopherbot commented Mar 24, 2021

thanm commented Mar 25, 2021

thanm commented Mar 25, 2021

dr2chase commented Mar 25, 2021

gopherbot commented Mar 30, 2021

thanm commented Mar 31, 2021

thanm commented Mar 31, 2021

thanm commented Apr 1, 2021

thanm commented Apr 2, 2021

gopherbot commented Apr 2, 2021

thanm commented Apr 7, 2021

thanm commented Apr 7, 2021

gopherbot commented Apr 8, 2021

gopherbot commented Apr 8, 2021

thanm commented Apr 8, 2021

thanm commented Apr 8, 2021

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

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

dr2chase commented Mar 7, 2021 •

edited

Loading