otherwise it fails spuriously with "newfunc allocated unexpectedly" message
when run with GOMAXPROCS>1 (other goroutine allocates).
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6347056
-lm must come after the source file, versions of gcc insist this strict order.
On standard compliant systems, we no longer need malloc.h for malloc.
Use pkg-config(1) to get correct glib cflags and libs.
Fix compiler warning in threadring.c and k-nucleotide.c.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6198076
CL 4313064 fixed its test case but did not address a
general enough problem:
type T1 struct { F *T2 }
type T2 T1
type T3 T2
could still end up copying the definition of T1 for T2
before T1 was done being evaluated, or T3 before T2
was done.
In order to propagate the updates correctly,
record a copy of an incomplete type for re-execution
once the type is completed. Roll back CL 4313064.
Fixes#3709.
R=ken2
CC=golang-dev, lstoakes
https://golang.org/cl/6301059
As discussed in
https://groups.google.com/d/msg/golang-dev/Na9XE6mcQyY/zbeBI7R-vnoJ
Here is a static copy of the go/parser benchmark. I ended up using
fancy encodings because the original parser.go had a number of `s
scattered throughout which made it hard to embed the source directly.
Curiously on my laptop this benchmark always scores roughly 10% higher
than the standalone benchmark. This may be down to the generation of
the fasta data set triggering the cpu governor to raise the cpu speed.
However the benchmark is consistent with itself across multiple runs.
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6305055
As discussed on golang-dev, reduce the size of the fasta
dataset to make it possible to run the go1 benchmarks on
small ARM systems.
Also, remove the 25m suffix from fasta data and Revcomp.
linux/arm: pandaboard OMAP4
BenchmarkBinaryTree17 1 70892426000 ns/op
BenchmarkFannkuch11 1 35712066000 ns/op
BenchmarkGobDecode 10 137146000 ns/op 5.60 MB/s
BenchmarkGobEncode 50 64953000 ns/op 11.82 MB/s
BenchmarkGzip 1 5675690000 ns/op 3.42 MB/s
BenchmarkGunzip 1 1207001000 ns/op 16.08 MB/s
BenchmarkJSONEncode 5 860424800 ns/op 2.26 MB/s
BenchmarkJSONDecode 1 3321839000 ns/op 0.58 MB/s
BenchmarkMandelbrot200 50 45893560 ns/op
BenchmarkRevcomp 10 135220300 ns/op 18.80 MB/s
BenchmarkTemplate 1 6385681000 ns/op 0.30 MB/s
R=rsc, minux.ma, dsymonds
CC=golang-dev
https://golang.org/cl/6278048
It is not necessary for the test to be effective and uses a
lot of resources in the compiler. Memory usage is halved and
compilation around 8x faster.
R=golang-dev, r, rsc, r
CC=golang-dev
https://golang.org/cl/6290044
We can't depend on init() order, and certainly we don't want to
register all future benchmarks that use jsonbytes or jsondata to init()
in json_test.go, so we use a more general solution: make generation of
jsonbytes and jsondata their own function so that the compiler will take
care of the order.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6282046
Most significant in mandelbrot, from avoiding MOVSD between registers,
but there are others.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6258063
Surprise! The C code is using floating point values for its counters.
Its off the critical path, but the Go code and C code are supposed to
be as similar as possible to make comparisons meaningful.
It doesn't have a significant effect.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6260058
Moving panic out of line speeds up fannkuch almost a factor of two.
Changes to bitwhacking code affect mandelbrot badly.
R=golang-dev, bradfitz, rsc, r
CC=golang-dev
https://golang.org/cl/6258056
for expr1, expr2 = range slice
was assigning to expr1 and expr2 in sequence
instead of in parallel. Now it assigns in parallel,
as it should. This matters for things like
for i, x[i] = range slice.
Fixes#3464.
R=ken2
CC=golang-dev
https://golang.org/cl/6252048
This is from CL 5451105 but was dropped from that CL.
See also CL 6137051.
The only change compared to 5451105 is to check for
h != nil in reflect·mapiterinit; allowing use of nil maps
must have happened after that original CL.
Fixes#3573.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/6215078
* Eliminate bounds check on known small shifts.
* Rewrite x<<s | x>>(32-s) as a rotate (constant s).
* More aggressive (but still minimal) range analysis.
R=ken, dave, iant
CC=golang-dev
https://golang.org/cl/6209077
There's no need for the 16-bit arithmetic here,
and it tickles a long-standing compiler bug.
Fix the exp code not to use 16-bit math and
create an explicit test for the compiler bug.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6256048
Not a complete fix for issue 3342, but fixes the trivial case.
There may still be a race in the instants before and after
a scavenger-induced garbage collection.
Intended to be "obviously safe": a call to runtime·gosched
before main.main is no different than a call to runtime.Gosched
at the beginning of main.main, and it is (or had better be)
safe to call runtime.Gosched at any point during main.
Update #3342.
R=iant
CC=golang-dev
https://golang.org/cl/5919052
Breaks closure test when GOMAXPROCS=2 or more.
««« original CL description
runtime: restore deadlock detection in the simplest case.
Fixes#3342.
R=iant, r, dave, rsc
CC=golang-dev, remy
https://golang.org/cl/5844051
»»»
R=rsc
CC=golang-dev
https://golang.org/cl/5924045
The two optimizations for small structs and arrays
were missing the implicit cast from ideal bool.
Fixes#3351.
R=rsc, lvd
CC=golang-dev
https://golang.org/cl/5848062
The spec is looser than the current implementation.
The spec edit was made in CL 4444050 (May 2011)
but I never implemented it.
Fixes#3244.
R=ken2
CC=golang-dev
https://golang.org/cl/5785049
This change is necessary to make the run shell script work
again, but it is not sufficient as bug424.go's execution line
does not name the package that it imports.
R=golang-dev, gri, rsc
CC=golang-dev
https://golang.org/cl/5771043
