- 15 Feb, 2015 3 commits
-
-
Dmitry Vyukov authored
Change 85e7bee1 introduced a bug: it marks map buckets as noscan when key and val do not contain pointers. However, buckets with large/outline key or val do contain pointers. This change takes key/val size into consideration when marking buckets as noscan. Change-Id: I7172a0df482657be39faa59e2579dd9f209cb54d Reviewed-on: https://go-review.googlesource.com/4901Reviewed-by:
Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Some rounding modes are affected by the sign of the value to be rounded. Make sure the sign is set before round is called. Added tests (that failed before the fix). Change-Id: Idd09b8fcbab89894fede0b9bc922cda5ddc87930 Reviewed-on: https://go-review.googlesource.com/4876Reviewed-by:
Rob Pike <r@golang.org>
-
Shenghou Ma authored
e.g. ·Name instead of package·Name for automatic stack map to be applied from its Go prototype. The underlying reason is that liblink look up name with suffix ".args_stackmap" for the stackmap coming from its Go prototype, but all the Go functions are named "".Name as this stage. Thus an assembly function named package·Name will never find its stackmap, which is named "".package.Name.args_stackmap. Perhaps cmd/vet should give a warning for this. Change-Id: I10d154a73ec969d574d20af877f747424350fbd1 Reviewed-on: https://go-review.googlesource.com/2588Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 14 Feb, 2015 9 commits
-
-
Shenghou Ma authored
Fixes #9824. Change-Id: Id318c61b6884e4fd294f7b0946dcc306f746ee0a Reviewed-on: https://go-review.googlesource.com/4891Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
This is an update of http://golang.org/cl/151410043 by Tim Shen. Change-Id: I43ab7fcedd785059c535f45a3c8cdb7b618c1499 Reviewed-on: https://go-review.googlesource.com/4873Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
TBR r, adonovan Change-Id: I1a38e2d724bf1147c7307a7e5ae855c42c60428c Reviewed-on: https://go-review.googlesource.com/4875Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
TBR adonovan Change-Id: I842cbc855dbd560f65e76c9a557dff1a22c5d610 Reviewed-on: https://go-review.googlesource.com/4882Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
TBR adonovan Change-Id: I4fd694101c2cf1c0c39bf73d16cab18502742dd9 Reviewed-on: https://go-review.googlesource.com/4881Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
TBR adonovan Change-Id: I30020f39be9183b37275e10a4fd1e1a3b4c48c89 Reviewed-on: https://go-review.googlesource.com/4880Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
Also: remove NewFloat - not needed anymore. Work-around for places where has been used so far: NewFloat(x, prec, mode) === new(Float).SetMode(mode).SetPrec(prec).SetFloat64(x) However, if mode == ToNearestEven, SetMode is not needed. SetPrec is needed if the default precision (53 after SetFloat64) is not adequate. TBR adonovan Change-Id: Ifda12c479ba157f2dea306c32b47c7afbf31e759 Reviewed-on: https://go-review.googlesource.com/4842Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
Also: - make representation more flexible (no need to store trailing 0 digits to match precision) - simplify rounding as a consequence - minor related fixes TBR adonovan Change-Id: Ie91075990688b506d28371ec3b633b8267397ebb Reviewed-on: https://go-review.googlesource.com/4841Reviewed-by:
Rob Pike <r@golang.org>
-
Robert Griesemer authored
TBR adonovan Change-Id: If77afa6474af6cad6512f6866725e3ae5acf2e3f Reviewed-on: https://go-review.googlesource.com/4840Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 13 Feb, 2015 28 commits
-
-
Brad Fitzpatrick authored
Per the comment at top, this test is about whether the GC runs during init, but it was testing more than that, and testing how much the GC collected in a certain amount of time. Instead, loosen this test to just see whether it ran at all and not how well it did. Fixes #9848 Change-Id: I31da7dd769140d7b49aa6c149a543fae6076aa5e Reviewed-on: https://go-review.googlesource.com/4820Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
David du Colombier authored
In CL 4050, NULL was used instead of nil. However, Plan 9 doesn't declare NULL. Change-Id: I8295a3102509a1ce417278f23a37cbf65938cce1 Reviewed-on: https://go-review.googlesource.com/4814Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
David Crawshaw authored
Android apps build again. Defining TLSG in runtime/tls_arm.s gives it the type SNOPTRBSS, so its type was never being set when GOOS=android. I considered modifying the if statement, but I no longer understand the intention of the original change (in d738c6b0). We were always setting it before, what platform is this not valid for? Fixes #9829 Change-Id: I3eaa4a9590893eff67695797eb22547a170cdbcd Reviewed-on: https://go-review.googlesource.com/4834Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: David Crawshaw <crawshaw@golang.org>
-
Hyang-Ah (Hana) Kim authored
--preserve flag is not a valid flag for some versions of cp. Change-Id: I57f5bf21cbe726057fdadcd55b040ef7ff5d7479 Reviewed-on: https://go-review.googlesource.com/4835Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Shenghou Ma authored
Fixes #9802. Change-Id: I22c52a37bdb23a14cc4615c9519431bb14ca81ca Reviewed-on: https://go-review.googlesource.com/4170Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Make cmd/ld a real library invoked by the individual linkers. There are no reverse symbol references anymore (symbols referred to in cmd/ld but defined in cmd/5l etc). This means that in principle we could do an automatic conversion of these to Go, as a stopgap until cmd/link is done or as a replacement for cmd/link. Change-Id: I4a94570257a3a7acc31601bfe0fad9dea0aea054 Reviewed-on: https://go-review.googlesource.com/4649Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
Change-Id: I2db4db852492eaddaf09dd7bae2fbd49f916e78a Reviewed-on: https://go-review.googlesource.com/4648Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
- remove a few uses of ? : - rename variables named len - rewrite a few gotos as nested switches - move goto targets to scope allowed by Go - use consistent return type of anyregalloc (was int or int32 in different places) - remove unused nr variable in agen - include proper headers in generated builtin1.c - avoid strange sized %E formats (%-6E, %2E) - change gengcmask argument from uint8[16] to uint8* (diagnosed by c2go; not an array in any real sense). - replace #ifdef XXX with comment block in 5g/peep.c - expand and remove FAIL macro from 5g - expand and remove noimpl macro from 9g - print regalloc errors to stdout in 8g (only use of fprint(2, ...) in all compilers) Still producing bit-for-bit identical output. Change-Id: Id46efcd2a89241082b234f63f375b66f2754d695 Reviewed-on: https://go-review.googlesource.com/4646Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
In mparith, all the a1-- are problematic. Rewrite it all without pointers. It's clearer anyway. In popt, v is problematic because it is used both as a fixed pointer (v = byvar[i]) and as a moving pointer (v = var; v++) aka slice. Eliminate pointer movement. Tested that this still produces bit-for-bit output for 'go build -a std' compared to d260756 (current master). Change-Id: I1a1bed0f98b594c3864fe95075dd95f9b52113e0 Reviewed-on: https://go-review.googlesource.com/4645Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Otherwise the exported variable collides with the type Arch. While we're here, remove arch.dumpit (now in portable code) and add arch.defframe (forgotten originally, somehow). Change-Id: I1b3a7dd7e96c5f632dba7cd6c1217b42a2004d72 Reviewed-on: https://go-review.googlesource.com/4644Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
If the Go source says x.y, and x is undefined, today we get undefined: x Change to: undefined: x in x.y Change-Id: I8ea95503bd469ea933c6bcbd675b7122a5d454f3 Reviewed-on: https://go-review.googlesource.com/4643Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Even with debugmerge = 1, the debugging output only happens with the -v command-line flag. This is useful because it gets added in automatically when debugging things like registerization with -R -v. Change-Id: I9a5c7f562507b72e8e2fe2686fd07d069721345a Reviewed-on: https://go-review.googlesource.com/4641Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Change-Id: I36f77e7ac7f727d8f3b51133f4b3ef93c35b09f6 Reviewed-on: https://go-review.googlesource.com/4640Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Noticed last week. Just saw a strange build failure in the revised rcmp (called by qsort on region) and this fixed it. Submitting first to avoid finding out which of my pending CLs tickled the problem. Change-Id: I4cafd611e2bf8e813e57ad0025e48bde5ae54359 Reviewed-on: https://go-review.googlesource.com/4830Reviewed-by:
Russ Cox <rsc@golang.org>
-
Russ Cox authored
When the compiler echoes back an expression, it shows the generated yacc expression. Change the generated code to use a slice so that $3 shows up as yyDollar[3] in such messages. Consider changing testdata/expr/expr.y to say: $$.Sub(float64($1), $3) (The float64 conversion is incorrect.) Before: expr.y:70[expr.go:486]: cannot convert exprS[exprpt - 2].num (type *big.Rat) to type float64 After: expr.y:70[expr.go:492]: cannot convert exprDollar[1].num (type *big.Rat) to type float64 Change-Id: I74e494069df588e62299d1fccb282f3658d8f8f4 Reviewed-on: https://go-review.googlesource.com/4630Reviewed-by:
Rob Pike <r@golang.org>
-
Roger Peppe authored
The current XML printer does not understand the xmlns attribute. This change changes it so that it interprets the xmlns attributes in the tokens being printed, and uses appropriate prefixes. Fixes #7535. Change-Id: I20fae291d20602d37deb41ed42fab4c9a50ec85d Reviewed-on: https://go-review.googlesource.com/2660Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Dmitry Vyukov authored
MOVQ RARG0, 0(SP) smashes exactly what was saved by PUSHQ R15. This code managed to work somehow with the current race runtime, but corrupts caller arguments with new race runtime that I am testing. Change-Id: I9ffe8b5eee86451db36e99dbf4d11f320192e576 Reviewed-on: https://go-review.googlesource.com/4810Reviewed-by:
Keith Randall <khr@golang.org>
-
Dmitry Vyukov authored
New race runtime is more scrupulous about env flags format. Change-Id: I2828bc737a8be3feae5288ccf034c52883f224d8 Reviewed-on: https://go-review.googlesource.com/4811Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
drainworkbuf is now gcDrain, since it drains until there's nothing left to drain. drainobjects is now gcDrainN because it's the bounded equivalent to gcDrain. The new names use the Go camel case convention because we have to start somewhere. The "gc" prefix is because we don't have runtime packages yet and just "drain" is too ambiguous. Change-Id: I88dbdf32e8ce4ce6c3b7e1f234664be9b76cb8fd Reviewed-on: https://go-review.googlesource.com/4785Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
All calls to drainworkbuf now pass true for this argument, so remove the argument and update the documentation to reflect the simplified interface. At a higher level, there are no longer any situations where we drain "one wbuf" (though drainworkbuf didn't guarantee this anyway). We either drain everything, or we drain a specific number of objects. Change-Id: Ib7ee0fde56577eff64232ee1e711ec57c4361335 Reviewed-on: https://go-review.googlesource.com/4784Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
scanblock is only called during _GCscan and _GCmarktermination. During _GCscan, scanblock didn't call drainworkbufs anyway. During _GCmarktermination, there's really no point in draining some (largely arbitrary) amount of work during the scanblock, since the GC is about to drain everything anyway, so simply eliminate this case. Change-Id: I7f3c59ce9186a83037c6f9e9b143181acd04c597 Reviewed-on: https://go-review.googlesource.com/4783Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
We no longer ever call scanblock with b == 0. Change-Id: I9b01da39595e0cc251668c24d58748d88f5f0792 Reviewed-on: https://go-review.googlesource.com/4782Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
scanblock(0, 0, nil, nil) was just a confusing way of saying wbuf = getpartialorempty() drainworkbuf(wbuf, true) Make drainworkbuf accept a nil workbuf and perform the getpartialorempty itself and replace all uses of scanblock(0, 0, nil, nil) with direct calls to drainworkbuf(nil, true). Change-Id: I7002a2f8f3eaf6aa85bbf17ccc81d7288acfef1c Reviewed-on: https://go-review.googlesource.com/4781Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Previously, scanblock called checknocurrentwbuf() after drainworkbuf(). Move this call into drainworkbuf so that every return path from drainworkbuf calls checknocurrentwbuf(). This is equivalent to the previous code because scanblock was the only caller of drainworkbuf. Change-Id: I96ef2168c8aa169bfc4d368f296342fa0fbeafb4 Reviewed-on: https://go-review.googlesource.com/4780Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Dmitry Vyukov authored
Currently we always create context objects for closures that capture variables. However, it is completely unnecessary for direct calls of closures (whether it is func()(), defer func()() or go func()()). This change transforms any OCALLFUNC(OCLOSURE) to normal function call. Closed variables become function arguments. This transformation is especially beneficial for go func(), because we do not need to allocate context object on heap. But it makes direct closure calls a bit faster as well (see BenchmarkClosureCall). On implementation level it required to introduce yet another compiler pass. However, the pass iterates only over xtop, so it should not be an issue. Transformation consists of two parts: closure transformation and call site transformation. We can't run these parts on different sides of escape analysis, because tree state is inconsistent. We can do both parts during typecheck, we don't know how to capture variables and don't have call site. We can't do both parts during walk of OCALLFUNC, because we can walk OCLOSURE body earlier. So now capturevars pass only decides how to capture variables (this info is required for escape analysis). New transformclosure pass, that runs just before order/walk, does all transformations of a closure. And later walk of OCALLFUNC(OCLOSURE) transforms call site. benchmark old ns/op new ns/op delta BenchmarkClosureCall 4.89 3.09 -36.81% BenchmarkCreateGoroutinesCapture 1634 1294 -20.81% benchmark old allocs new allocs delta BenchmarkCreateGoroutinesCapture 6 2 -66.67% benchmark old bytes new bytes delta BenchmarkCreateGoroutinesCapture 176 48 -72.73% Change-Id: Ic85e1706e18c3235cc45b3c0c031a9c1cdb7a40e Reviewed-on: https://go-review.googlesource.com/4050Reviewed-by:
Russ Cox <rsc@golang.org>
-
Shenghou Ma authored
The only remaining uses of four spaces instead of a tab is when the line is too long (e.g. type Package). Fixes #9809 Change-Id: Ifffd3639aa9264e795686ef1879a7686f182d2e5 Reviewed-on: https://go-review.googlesource.com/4182Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Dmitry Vyukov authored
This was accidentially removed in: https://go-review.googlesource.com/#/c/3508/8/src/cmd/gc/reflect.c Change-Id: I06dd5bb0cb3e2811bd4ef605d7a5225cfa033fe0 Reviewed-on: https://go-review.googlesource.com/4731Reviewed-by:
Keith Randall <khr@golang.org>
-
Dmitry Vyukov authored
Change-Id: I7c41cc6a5ab9fb3b0cc3812cf7e9776884658778 Reviewed-on: https://go-review.googlesource.com/4671Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-