Issue 1:
Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
W7/32b in VirtualBox running in Ubuntu 12.04, x86_64.

Which version are you using? (run 'go version')
go version 1.1.2

Please provide any additional information below.

Excerpts from a mail converstaion with the Camlistore developers:

----
We've just got this report:
http://camlistore.org/issue/214

so I've tried in winxp in a virtualbox a very basic test like
https://gist.github.com/mpl/6366649
and I indeed get an error like:
kv.Create foo.kv: read foo.kv: Fin de fichier atteinte. (which means EOF)
----
First partial result:

C:\home\src\github.com\cznic\kv>go test -run TestCreate$

The problem is here: https://github.com/cznic/exp/blob/master/lldb/xact.go#L211
The first call to ReadAt(112 bytes at offset 16) at L211, returns
correctly (0, err) on Linux - the file is only 16 bytes long at that
moment (that's the kv header). 'err' is such that 'err == io.EOF' is
true.

However, on Windows the error is("%T(%#v)"):
*os.PathError(&os.PathError{Op:"read", Path:"_testdata/tempname",
Err:0x26})

and for this 'err == io.EOF' is false. Which breaks the logic the DB
engine relies on.

FYI: Some info about 0x26 error here:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/1a16311b-c625-46cf-830b-6a26af488435/how-to-solve-error-38-0x26-errorhandleeof-using-fsctlgetretrievalpointers
From that link it may also be the case that it's actually a Windows
bug (happens only for small files).
----

====

I'm aware that this issue report is lacking a small, self contained reproduction case.
I'm trying to first figure out if the 0x26 error should be translated to an io.EOF by
the Go runtime on Windows - or not?

If a small reproduction case turns out to be unavoidable, I'll attempt to prepare one
over the weekend.

Issue 2:
by austin@google.com:

What steps will reproduce the problem?
1. GOARCH=power64 go run run.go -- nilptr2.go

Lines marked "removed repeated nil check" fail in this test because the test
depends on duplicate store elimination, which doesn't currently happen on power64x.

To see the cause, run
GOARCH=power64 gdb --args $(go tool -n 9g) nilptr3.go
br nilopt
r
dis 1
set debug_checknil = 2
c

On power64, prior to nilopt, f2 looks like
0:00041 (nilptr3.go:64) TEXT "".f2(SB),$0-0
0:00042 (nilptr3.go:64) FUNCDATA $0,"".gcargs·2(SB)
0:00043 (nilptr3.go:64) FUNCDATA $1,"".gclocals·3(SB)
0:00052 (nilptr3.go:66) MOVD $0,R7
0:00053 (nilptr3.go:66) MOVD R7,"".intp-0(SP)
0:00054 (nilptr3.go:67) MOVD $0,R7
0:00055 (nilptr3.go:67) MOVD R7,"".arrayp-0(SP)
0:00056 (nilptr3.go:68) MOVD $0,R7
0:00057 (nilptr3.go:68) MOVD R7,"".array0p-0(SP)
0:00058 (nilptr3.go:69) MOVD $0,R7
0:00059 (nilptr3.go:69) MOVD R7,"".bigarrayp-0(SP)
0:00060 (nilptr3.go:70) MOVD $0,R7
0:00061 (nilptr3.go:70) MOVD R7,"".structp-0(SP)
0:00062 (nilptr3.go:71) MOVD $0,R7
0:00063 (nilptr3.go:71) MOVD R7,"".bigstructp-0(SP)
0:00064 (nilptr3.go:72) MOVD $0,R7
0:00065 (nilptr3.go:72) MOVD R7,"".emptyp-0(SP)
0:00066 (nilptr3.go:73) MOVD $0,R7
0:00067 (nilptr3.go:73) MOVD R7,"".empty1p-0(SP)
0:00068 (nilptr3.go:76) MOVD "".intp-0(SP),R7
0:00069 (nilptr3.go:76) CHECKNIL R7,
0:00070 (nilptr3.go:77) MOVD "".arrayp-0(SP),R7
0:00071 (nilptr3.go:77) CHECKNIL R7,
0:00072 (nilptr3.go:78) MOVD "".array0p-0(SP),R7
0:00073 (nilptr3.go:78) CHECKNIL R7,
0:00074 (nilptr3.go:79) MOVD "".array0p-0(SP),R7
0:00075 (nilptr3.go:79) CHECKNIL R7,
0:00076 (nilptr3.go:80) MOVD "".intp-0(SP),R7
0:00077 (nilptr3.go:80) CHECKNIL R7,
0:00078 (nilptr3.go:81) MOVD "".arrayp-0(SP),R7
0:00079 (nilptr3.go:81) CHECKNIL R7,
0:00080 (nilptr3.go:82) MOVD "".structp-0(SP),R7
0:00081 (nilptr3.go:82) CHECKNIL R7,
0:00082 (nilptr3.go:83) MOVD "".emptyp-0(SP),R7
0:00083 (nilptr3.go:83) CHECKNIL R7,
0:00084 (nilptr3.go:84) MOVD "".arrayp-0(SP),R7
0:00085 (nilptr3.go:84) CHECKNIL R7,
0:00086 (nilptr3.go:85) MOVD "".bigarrayp-0(SP),R7
0:00087 (nilptr3.go:85) CHECKNIL R7,
0:00088 (nilptr3.go:86) MOVD "".bigstructp-0(SP),R7
0:00089 (nilptr3.go:86) CHECKNIL R7,
0:00090 (nilptr3.go:87) MOVD "".empty1p-0(SP),R7
0:00091 (nilptr3.go:87) CHECKNIL R7,
0:00092 (nilptr3.go:88) RETURN ,

These extra MOVDs inhibit the repeated nil check optimization. In contrast, on amd64,
prior to nilopt, f2 looks like
0:00032 (nilptr3.go:64) TEXT "".f2+0(SB),$0-0
0:00033 (nilptr3.go:64) FUNCDATA $0,"".gcargs·2+0(SB)
0:00034 (nilptr3.go:64) FUNCDATA $1,"".gclocals·3+0(SB)
0:00043 (nilptr3.go:66) MOVQ $0,DX
0:00044 (nilptr3.go:67) MOVQ $0,AX
0:00045 (nilptr3.go:68) MOVQ $0,CX
0:00046 (nilptr3.go:69) MOVQ $0,R8
0:00047 (nilptr3.go:70) MOVQ $0,DI
0:00048 (nilptr3.go:71) MOVQ $0,SI
0:00049 (nilptr3.go:72) MOVQ $0,BP
0:00050 (nilptr3.go:73) MOVQ $0,BX
0:00051 (nilptr3.go:76) CHECKNIL DX,
0:00052 (nilptr3.go:77) CHECKNIL AX,
0:00053 (nilptr3.go:78) CHECKNIL CX,
0:00054 (nilptr3.go:79) CHECKNIL CX,
0:00055 (nilptr3.go:80) CHECKNIL DX,
0:00056 (nilptr3.go:81) CHECKNIL AX,
0:00057 (nilptr3.go:82) CHECKNIL DI,
0:00058 (nilptr3.go:83) CHECKNIL BP,
0:00059 (nilptr3.go:84) CHECKNIL AX,
0:00060 (nilptr3.go:85) CHECKNIL R8,
0:00061 (nilptr3.go:86) CHECKNIL SI,
0:00062 (nilptr3.go:87) CHECKNIL BX,
0:00063 (nilptr3.go:88) RET ,