gllgo: unexpected signal during runtime execution (2)

[dvyukov]

I am on commit a143e91 in libgo branch.

Build the following program with gllgo:
https://gist.github.com/dvyukov/72e671c973db993f3c18

Build crashes in llvm code:

$ go build -compiler=gccgo /tmp/llgo1.go
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x1003d7afa8 pc=0xe6882a]

runtime stack:
runtime.throw(0x2f71365)
src/pkg/runtime/panic.c:520 +0x69 fp=0x7fff463aa0c8
runtime: unexpected return pc for runtime.sigpanic called from 0xe6882a
runtime.sigpanic()
src/pkg/runtime/os_linux.c:222 +0x3d fp=0x7fff463aa0e0

goroutine 16 [syscall]:
runtime.cgocall(0xa991f0, 0xc208181a30)
src/pkg/runtime/cgocall.c:143 +0xe5 fp=0xc208181a18
github.com/go-llvm/llvm._Cfunc_LLVMTargetMachineEmitToMemoryBuffer(0x3d3a830, 0x3c347a0, 0x1, 0xc20803af60, 0xc20803af68, 0x3d0af70)
github.com/go-llvm/llvm/_obj/_cgo_defun.c:5072 +0x31 fp=0xc208181a30
github.com/go-llvm/llvm.TargetMachine.EmitToMemoryBuffer(0x3d3a830, 0x3c347a0, 0x1, 0x2097d10, 0x0, 0x2097d10)
github.com/go-llvm/llvm/target.go:254 +0x79 fp=0xc208181aa0
main.performAction(0xc20802a0d0, 0x1, 0xc208000540, 0x1, 0x1, 0x7fff463ad13e, 0x39, 0x0, 0x0)
github.com/go-llvm/llgo/cmd/gllgo/gllgo.go:381 +0x4ce fp=0xc208181cd8
main.performActions(0xc20802a0d0, 0x0, 0x0)
github.com/go-llvm/llgo/cmd/gllgo/gllgo.go:481 +0x2b0 fp=0xc208181e28
main.main()
github.com/go-llvm/llgo/cmd/gllgo/gllgo.go:505 +0xf3 fp=0xc208181f50
runtime.main()
src/pkg/runtime/proc.c:247 +0x11a fp=0xc208181fa8

[axw]

I've just tried to repro this, and I get a different error with trunk (over on llvm.org):

panic: Instruction not visited yet

goroutine 16 [running]:
runtime.panic(0x26857a0, 0xc20809a6a0)
    /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
llvm.org/llgo/irgen.(*frame).value(0xc2080038c0, 0x7eff0d2f94c0, 0xc208004a20, 0x52a0fe0)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:663 +0x6c4
llvm.org/llgo/irgen.(*frame).llvmvalue(0xc2080038c0, 0x7eff0d2f94c0, 0xc208004a20, 0x0)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:667 +0x44
llvm.org/llgo/irgen.(*frame).instruction(0xc2080038c0, 0x7eff0d2f9470, 0xc208004a80)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:957 +0x6b76
llvm.org/llgo/irgen.(*frame).translateBlock(0xc2080038c0, 0xc2080464d0, 0x529f590)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:625 +0xcd
llvm.org/llgo/irgen.(*unit).defineFunction(0xc2080172c0, 0xc208040500)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:419 +0x1d37
llvm.org/llgo/irgen.(*unit).defineFunctionsInOrder(0xc2080172c0, 0xc20809c210)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:159 +0x240
llvm.org/llgo/irgen.(*unit).translatePackage(0xc2080172c0, 0xc20804a380)
    /media/msata/code/src/llvm.org/llgo/irgen/ssa.go:197 +0x372
llvm.org/llgo/irgen.(*compiler).compile(0xc2080260d0, 0xc2080001d0, 0x1, 0x1, 0xc208000620, 0x4, 0x0, 0x0, 0x0)
    /media/msata/code/src/llvm.org/llgo/irgen/compiler.go:249 +0xade
llvm.org/llgo/irgen.(*Compiler).Compile(0xc208048510, 0xc2080001d0, 0x1, 0x1, 0x0, 0x0, 0x7eff0d169828, 0x0, 0x0)
    /media/msata/code/src/llvm.org/llgo/irgen/compiler.go:115 +0x154
main.performAction(0xc208076000, 0x0, 0xc2080001d0, 0x1, 0x1, 0xc2080001f7, 0x5, 0x0, 0x0)
    /media/msata/code/src/llvm.org/llgo/cmd/gllgo/gllgo.go:575 +0x106
main.performActions(0xc208076000, 0x0, 0x0)
    /media/msata/code/src/llvm.org/llgo/cmd/gllgo/gllgo.go:782 +0x5dc
main.main()
    /media/msata/code/src/llvm.org/llgo/cmd/gllgo/gllgo.go:806 +0x11b

And I minimised the test case to:

package main

type X struct {
    indices [1]int
}

func main() {
    _ = [1]int{}[X{}.indices[0]]
}

The panic is caused by some overzealous code that tries to avoid loading pointers when extracting fields and array elements. I'll transcribe this bug into llvm.org/bugs when it's set up for llgo.