test: for issue11656 try to execute trap, not call it

The issue11656 code was using the trap instruction as a PC value,
but it is intended to call a PC value that contains the trap instruction.

It doesn't matter too much as in practice the address is not
executable anyhow. But may as well have the code act the way it
is documented to act.

Also, don't run the test with gccgo/GoLLVM, as it can't work.
The illegal instruction will have no unwind data, so the unwinder
won't be able to get past it. In other words, gccgo/GoLLVM suffer
from the exact problem that the issue describes, but it seems insoluble.

For golang/go#11656

Change-Id: Ib2e50ffc91d215fd50e78f742fafe476c92d704e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278473
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

test/fixedbugs/issue11656.go

@@ -12,6 +12,11 @@
 // wasm does not work, because the linear memory is not executable.
 // +build !wasm
 
+// This test doesn't work on gccgo/GoLLVM, because they will not find
+// any unwind information for the artificial function, and will not be
+// able to unwind past that point.
+// +build !gccgo
+
 package main
 
 import (
@@ -75,6 +80,7 @@ func f(n int) {
 	}
 
 	f.x = uintptr(unsafe.Pointer(&ill[0]))
-	fn := *(*func())(unsafe.Pointer(&f))
+	p := &f
+	fn := *(*func())(unsafe.Pointer(&p))
 	fn()
 }