pkg fmt test failure on ARM

[minux]

What steps will reproduce the problem?
do gotest in src/pkg/fmt

What is the expected output?
PASS

What do you see instead?
--- FAIL: fmt_test.TestCountMallocs (0.22 seconds)
    fmt_test.go:542: Sprintf("%g"): expected 1 mallocs, got 2
FAIL

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

Which operating system are you using?
Linux

Which revision are you using?  (hg identify)
9321a5705307 tip


Please provide any additional information below.
I tested on both Android debian chroot and qemu-arm emulator.

[minux]

Comment 1:

I've also tried setting GOARM=5, no change in result.

[robpike]

Comment 2:

Labels changed: added priority-go1.

[robpike]

Comment 3:

Status changed to Accepted.

[robpike]

Comment 4:

Owner changed to builder@golang.org.

[krasin]

Comment 5:

Not reproducible on my machine (Ubuntu 11.10 Oneiric, PandaBoard) and the latest Go
revision:
hg identify
f5142a5cac19 tip
...
ok      fmt 0.279s
Testing the revision mentioned by topic starter:
hg identify
9321a5705307
...
ok      fmt

[davecheney]

Comment 6:

Possibly still a problem on older arm5 hardware
stora(~/go/src) % make -C pkg/fmt test
make: Entering directory `/home/dfc/go/src/pkg/fmt'
gotest
rm -f _test/fmt.a
rm -f _test/fmt.a
gopack grc _test/fmt.a _gotest_.5 
--- FAIL: fmt_test.TestCountMallocs (0.10 seconds)
        fmt_test.go:542: Sprintf("%g"): expected 1 mallocs, got 2
FAIL
gotest: "./5.out" failed: exit status 1
make: *** [test] Error 2
make: Leaving directory `/home/dfc/go/src/pkg/fmt'
stora(~/go/src) % hg identify
uname -a
0ebf155c8d5a+ tip
stora(~/go/src) % uname -a
Linux stora.local 2.6.34-rc2-g85354d2 #1 PREEMPT Fri Mar 26 07:21:32 PDT 2010 armv5tel
GNU/Linux

[davecheney]

Comment 7:

Re: comment 5, it looks like the malloc test does not run in short mode, which is what
./all.bash uses. 
Please see http://golang.org/cl/5544067/.
If you do make -C $GOROOT/src/pkg/fmt test this will run the full test set, with or
without the CL above.
Please let me know if you see the test fail.
I have bisected back to weekly.2011-12-22 but have not yet found where this test started
to break.

[davecheney]

Comment 8:

This failure is not present in weekly.2011-12-14, however at that point %g generated 6
mallocs. Subsequently this alloc count was improved to 2, then this commit reduced the
expected count to 1
http://code.google.com/p/go/source/detail?r=11ab63c03100b6ef9e6d0217967191e9033794f0
However, after investigating it this test currently fails on darwin/386 at tip.
imac(~/go/src) % hg identify
518f09c59498 tip
imac(~/go/src) % make -C pkg/fmt test
gotest
rm -f _test/fmt.a
rm -f _test/fmt.a
gopack grc _test/fmt.a _gotest_.8 
--- FAIL: fmt_test.TestCountMallocs (0.01 seconds)
    fmt_test.go:542: Sprintf("%g"): expected 1 mallocs, got 2
FAIL
gotest: "./8.out" failed: exit status 1
make: *** [test] Error 2
My hypothesis is %g takes 2 allocs on all 32 bit platforms, and 1 on 64bit platforms but
nobody noticed because the alloc test doesn't run in short mode.

[krasin]

Comment 9:

Dave, what is a short mode? I may be missing something.

[minux]

Comment 10:

Re Comment 8: Confirm your hypothesis on Linux/386 and Darwin/386. Have you started
tracing this bug? If not, I would like to debug this.
Re Comment 9: "./?.out -test.short" is the short mode, and it will omit some lengthy
tests. This bug is only triggered in the non-short test mode (although testing it won't
take long).

[davecheney]

Comment 11:

Minux, please feel free to take a look. Some points which may (or may not) be useful:
* If you cast the call to Sprintf  to float32(3.14159) then only one allocation is used,
which is strange because the internal formatFloat routine expects a float64 so there are
lots of conversions between float32 -> float64 -> uint64.
* This commit,
http://code.google.com/p/go/source/detail?r=6cfb9f2415fab4b8fed834afac05afeb9fb9ee8b,
improved the count from 6 to 2, it is possible it reduced it to 1 on 64bit machines
unintentionally, or perhaps a later change improved for 64bit hosts unintentionally.

[robpike]

Comment 12:

Owner changed to @robpike.

[robpike]

Comment 13:

This issue was closed by revision 45d7397.

Status changed to Fixed.