Comment 1 by eadfrith:

I can recreate this with 8g in Ubuntu 9.4
Here's a much simpler test that isolates the issue:
package main
import (
  "fmt";
)
func aint() float {
  return 0;
}
func main() {
  for i := 0; i < 8; i++ {
    y := int(aint());
    fmt.Println("step ",i, ": y ", y);
  }
}
Output:
step  0 : y  0
step  1 : y  0
step  2 : y  0
step  3 : y  0
step  4 : y  0
step  5 : y  0
step  6 : y  0
step  7 : y  -2147483648

Attachments:

1. issue310.go (186 bytes)

Comment 2:

Looks like the 8g-generated code is not 
managing the x87 floating point stack correctly.
Thanks for the nice simple test case.

Owner changed to r...@golang.org.

Status changed to Accepted.

Comment 4:

Issue #322 has been merged into this issue.

Comment 5:

If the example program in Comment 1 by eadfrith is modified like this:
...
12: func main() {
13:   var y int16;
14:   for i := 0; i < 8; i++ {
15:     y = int16(aint());
16:     fmt.Println("step ",i, ": y ", y);
17:   }
18: }
The 8g compile fails and says:
Issue310.go:16: reg: unknown op: FMOVWP

Comment 6:

While I'm not familiar with the assembly language generated by the 8g compiler, I can
see the problem.  Here is the code:
...
0015 (issue310.go:13) CALL    ,aint+0(SB)
0016 (issue310.go:13) FMOVF   (SP),F0
0017 (issue310.go:13) FMOVD   F0,F0
0018 (issue310.go:13) FSTCW   ,.noname+-34(SP)
0019 (issue310.go:13) MOVW    $3967,.noname+-36(SP)
0020 (issue310.go:13) FLDCW   .noname+-36(SP),
0021 (issue310.go:13) FMOVLP  F0,y+-32(SP)
0022 (issue310.go:13) FLDCW   .noname+-34(SP),
...
Here is the comment from gsubr.c:
...
1527:        case CASE(TFLOAT32, TFLOAT32):
1528:        case CASE(TFLOAT64, TFLOAT64):
1529:                // The way the code generator uses floating-point
1530:                // registers, a move from F0 to F0 is intended as a no-op.
1531:                // On the x86, it's not: it pushes a second copy of F0
1532:                // on the floating point stack.  So toss it away here.
1533:                // Also, F0 is the *only* register we ever evaluate
1534:                // into, so we should only see register/register as F0/F0.
...
It is clear that the FMOVD F0,F0 is not being tossed away.
Sadly, this observation does not help with the problem in Comment 5.

Comment 7:

This issue was closed by revision e1c347c.

Status changed to Fixed.

Merged into issue #-.