Comment 1 by andrea.fazzi@alcacoop.it:

The program doesn't crash anymore when the following patch is applied:
--- main.go.original    2013-12-31 00:49:27.353031123 +0100
+++ main.go 2013-12-31 08:36:19.763468679 +0100
@@ -9,7 +9,8 @@
 
 func HomogRotate3D(angle float32, axis Vec3f) Mat4f {
    x, y, z := axis[0], axis[1], axis[2]
-   s, c := float32(math.Sin(float64(angle))), float32(math.Cos(float64(angle)))
+   s := float32(math.Sin(float64(angle)))
+   c := float32(math.Cos(float64(angle)))
    k := 1 - c
    return Mat4f{x*x*k + c, x*y*k + z*s, x*z*k - y*s, 0, x*y*k - z*s, y*y*k + c, y*z*k + x*s, 0, x*z*k + y*s, y*z*k - x*s, z*z*k + c, 0, 0, 0, 0, 1}
 }

Comment 2:

It looks like your Go install has GOARM=5 hard coded.
udoo(~/src) % GOARM=6 go run boom.go                                            
udoo(~/src) % GOARM=5 go run boom.go 
stepflt 0x10ca4 0xeebf8bc2
Unsupported floating point instruction
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x347f0]
goroutine 1 [running]:
runtime.panic(0x39518, 0x6d348)
        /home/dfc/go/src/pkg/runtime/panic.c:264 +0x134
runtime: unexpected return pc for stepflt called from 0x0
goroutine 2 [runnable]:
runtime.MHeap_Scavenger()
        /home/dfc/go/src/pkg/runtime/mheap.c:439
runtime.goexit()
        /home/dfc/go/src/pkg/runtime/proc.c:1394
exit status 2
Applying the fix,
//        s, c := float32(math.Sin(float64(angle))), float32(math.Cos(float64(angle)))
        s := float32(math.Sin(float64(angle)))
          c := float32(math.Cos(float64(angle)))
solves the runtime error. I think we have to teach the soft float impl how to handle
this opcode, and you should figure out why your Go install is compiled in softfloat mode.

Labels changed: added release-go1.3, repo-main, arch-arm.

Status changed to Accepted.

Comment 3:

I think there might be two issues here.
1. stepflt cannot handle this instruction, because it is new, we've never seen it before
2. because it's a new instruction, it may actually be a VFPv3 instruction, not a VFPv1
(bcm2385) instruction so will need to be gated using GOARM=7 as we do for vmov (?).
I'll crack out my RPi later this evening and check item 2 and create a related issue if
this is indeed the case.

Comment 4:

@andrea, sorry I didn't believe you, and now I've made a mess out of these issues. 
I'll leave this one for the softfloat issue and have opened issue #7044 for the RPi issue.

Comment 5 by andrea.fazzi@alcacoop.it:

Doubt is the basis of science :) 
I think I've got a similar issue running the same code on a Samsung GT-S5280 with a
Cortex A5 CPU. This time it doesn't SIGILL but the calculation inside HomogRotate3D is
wrong and produces a corrupted rendering. Should I open a new issue once I'll be able to
produce a more detailed report?

Comment 6:

Yes, have a look at the instruction generated in the other issue. It's trying to sign
extend a fixed point (not an int) to a floating point number.
Can you please add something to check the output of the function and post that in the
issue body.

Comment 7:

This isn't a softfloat error, the compiler is generating the wrong opcode.

Status changed to Duplicate.

Merged into issue #7044.