On Fri, Feb 2, 2018 at 6:14 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > >> This patch to the Go frontend changes value methods to always check >> that the pointer they are passed is not nil. We already dereference >> the pointer to copy the value, but if the method does not use the >> value then the pointer dereference may be optimized away. Do an >> explicit nil check so that we get the panic that is required by the >> language. This fixes https://golang.org/issue/19806. I added a test >> case to gcc/testsuite/go.go-torture/execute to test this at various >> optimization levels; the test used to fail at -O1 and above. >> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed >> to mainline. >> >> Ian >> >> 2018-01-31 Ian Lance Taylor <i...@golang.org> >> >> * go.go-torture/execute/printnil.go: New test. > > the new test FAILs on Solaris 10, sparc and x86 (only, 11 is fine) at > all optimization levels: > > +FAIL: go.go-torture/execute/printnil.go execution, -O0 > +FAIL: go.go-torture/execute/printnil.go execution, -O1 > +FAIL: go.go-torture/execute/printnil.go execution, -O2 > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fbounds-check > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer > -finline-functions > +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fomit-frame-pointer > -finline-functions -funroll-loops > +FAIL: go.go-torture/execute/printnil.go execution, -O3 -g > +FAIL: go.go-torture/execute/printnil.go execution, -Os > > Don't know yet what the difference is, though. Here's the failing > stacktrace: > > #0 runtime.gopanic (e=...) > at /vol/gcc/src/hg/trunk/solaris/libgo/go/runtime/panic.go:423 > #1 0xfffffd7ffe492705 in runtime_panicstring ( > s=s@entry=0xfffffd7ffe98d425 "nil pointer dereference") > at /vol/gcc/src/hg/trunk/solaris/libgo/runtime/panic.c:38 > #2 0xfffffd7ffe49168b in __go_runtime_error (i=<optimized out>) > at /vol/gcc/src/hg/trunk/solaris/libgo/runtime/go-runtime-error.c:76 > #3 0x0000000000402a97 in main.MyType.String () > at > /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/go.go-torture/execute/printnil.go:11 > #4 0xfffffd7ffe5d15f5 in fmt.pp.handleMethods (p=p@entry=0xc4200a2180, > verb=verb@entry=115) > at /vol/gcc/src/hg/trunk/solaris/libgo/go/fmt/print.go:603 > #5 0xfffffd7ffe5d0e2b in fmt.pp.printArg (p=p@entry=0xc4200a2180, arg=..., > verb=115) at /vol/gcc/src/hg/trunk/solaris/libgo/go/fmt/print.go:686 > #6 0xfffffd7ffe5d2794 in fmt.pp.doPrintf (p=p@entry=0xc4200a2180, format=..., > a=...) at /vol/gcc/src/hg/trunk/solaris/libgo/go/fmt/print.go:1003 > #7 0xfffffd7ffe5d2cd6 in fmt.Sprintf (format=..., a=...) > at /vol/gcc/src/hg/trunk/solaris/libgo/go/fmt/print.go:203 > #8 0x0000000000402b73 in main.main () > at > /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/go.go-torture/execute/printnil.go:16 > > At first I thought this might be related to Solaris 10 printf not > handling printf (NULL).
It's normal for that panic to occur. That's not the point of failure. The panic should be caught by the recover call in catchPanic (libgo/go/fmt/print.go line 531). Does that code get executed? What happens after that? Ian
