- 18 Feb, 2014 9 commits
-
-
Brad Fitzpatrick authored
Unbreaks the build. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/65650043
-
Rob Pike authored
LGTM=mpvl R=mpvl CC=golang-codereviews https://golang.org/cl/65550044
-
Marcel van Lohuizen authored
This is a relatively minor change. This does not result in changes to go.text/unicode/norm. The go.text packages will therefore be relatively unaffected. It does make the way for an upgrade to CLDR 24, though. The tests of all.bash pass, as well as the tests in go.text after this update. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/65400044
-
Alex Brainman authored
LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/64980043
-
Andrew Gerrand authored
LGTM=r R=r CC=golang-codereviews https://golang.org/cl/64910043
-
Russ Cox authored
broke 32-bit builds ««« original CL description cmd/gc, runtime: enable precisestack by default Precisestack makes stack collection completely precise, in the sense that there are no "used and not set" errors in the collection of stack frames, no times where the collector reads a pointer from a stack word that has not actually been initialized with a pointer (possibly a nil pointer) in that function. The most important part is interfaces: precisestack means that if reading an interface value, the interface value is guaranteed to be initialized, meaning that the type word can be relied upon to be either nil or a valid interface type word describing the data word. This requires additional zeroing of certain values on the stack on entry, which right now costs about 5% overall execution time in all.bash. That cost will come down before Go 1.3 (issue 7345). There are at least two known garbage collector bugs right now, issues 7343 and 7344. The first happens even without precisestack. The second I have only seen with precisestack, but that does not mean that precisestack is what causes it. In fact it is very difficult to explain by what precisestack does directly. Precisestack may be exacerbating an existing problem. Both of those issues are marked for Go 1.3 as well. The reasons for enabling precisestack now are to give it more time to soak and because the copying stack work depends on it. LGTM=r R=r CC=golang-codereviews, iant, khr https://golang.org/cl/64100044 »»» TBR=r CC=golang-codereviews https://golang.org/cl/65230043
-
Nigel Tao authored
LGTM=dsymonds R=dsymonds CC=golang-codereviews https://golang.org/cl/64100045
-
Russ Cox authored
Precisestack makes stack collection completely precise, in the sense that there are no "used and not set" errors in the collection of stack frames, no times where the collector reads a pointer from a stack word that has not actually been initialized with a pointer (possibly a nil pointer) in that function. The most important part is interfaces: precisestack means that if reading an interface value, the interface value is guaranteed to be initialized, meaning that the type word can be relied upon to be either nil or a valid interface type word describing the data word. This requires additional zeroing of certain values on the stack on entry, which right now costs about 5% overall execution time in all.bash. That cost will come down before Go 1.3 (issue 7345). There are at least two known garbage collector bugs right now, issues 7343 and 7344. The first happens even without precisestack. The second I have only seen with precisestack, but that does not mean that precisestack is what causes it. In fact it is very difficult to explain by what precisestack does directly. Precisestack may be exacerbating an existing problem. Both of those issues are marked for Go 1.3 as well. The reasons for enabling precisestack now are to give it more time to soak and because the copying stack work depends on it. LGTM=r R=r CC=golang-codereviews, iant, khr https://golang.org/cl/64100044
-
Russ Cox authored
I have seen this cause leaks where not all objects in a sync.Pool would be reclaimed during the sync package tests. I found it while debugging the '0 of 100 finalized' failure we are seeing on arm, but it seems not to be the root cause for that one. LGTM=dave, dvyukov R=golang-codereviews, dave, dvyukov CC=golang-codereviews https://golang.org/cl/64920044
-
- 17 Feb, 2014 5 commits
-
-
Dave Cheney authored
Callers of md5.Sum should do so to avoid allocations, the example did not demonstate this property. ««« original CL description crypto/md5: add example for Sum LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/64820044 »»» LGTM=minux.ma R=r, minux.ma CC=golang-codereviews https://golang.org/cl/65180043
-
ChaiShushan authored
LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/64820044
-
Ian Lance Taylor authored
LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/64090043
-
Dmitriy Vyukov authored
Add b.RunParallel function that captures parallel benchmark boilerplate: creates worker goroutines, joins worker goroutines, distributes work among them in an efficient way, auto-tunes grain size. Fixes #7090. R=bradfitz, iant, josharian, tracey.brendan, r, rsc, gobot CC=golang-codereviews https://golang.org/cl/57270043
-
Dmitriy Vyukov authored
Is it required? Why don't we do it? R=bradfitz CC=golang-codereviews https://golang.org/cl/61150043
-
- 16 Feb, 2014 5 commits
-
-
Dave Cheney authored
Update #7331 cgo is currently broken on freebsd/arm. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/63900043
-
Russ Cox authored
CL 64170043 disabled it in run.bash for Unix systems. I did not realize Windows systems also ran the race detector test. TBR=iant CC=golang-codereviews https://golang.org/cl/64480043
-
Russ Cox authored
Not recording the address being taken was causing the liveness analysis not to preserve x in the absence of direct references to x, which in turn was making the net test fail with GOGC=0. In addition to the test, this fixes a bug wherein GOGC=0 go test -short net crashed if liveness analysis was in use (like at tip, not like Go 1.2). TBR=ken2 CC=golang-codereviews https://golang.org/cl/64470043
-
Russ Cox authored
This problem was discovered by reading the code. I have not seen it in practice, nor do I have any ideas on how to trigger it reliably in a test. But it's still worth fixing. TBR=ken2 CC=golang-codereviews https://golang.org/cl/64370046
-
Russ Cox authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/64380043
-
- 15 Feb, 2014 3 commits
-
-
Russ Cox authored
The VARDEF placement must be before the initialization but after any final use. If you have something like s = ... using s ... the rhs must be evaluated, then the VARDEF, then the lhs assigned. There is a large comment in pgen.c on gvardef explaining this in more detail. This CL also includes Ian's suggestions from earlier CLs, namely commenting the use of mode in link.h and fixing the precedence of the ~r check in dcl.c. This CL enables the check that if liveness analysis decides a variable is live on entry to the function, that variable must be a function parameter (not a result, and not a local variable). If this check fails, it indicates a bug in the liveness analysis or in the generated code being analyzed. The race detector generates invalid code for append(x, y...). The code declares a temporary t and then uses cap(t) before initializing t. The new liveness check catches this bug and stops the compiler from writing out the buggy code. Consequently, this CL disables the race detector tests in run.bash until the race detector bug can be fixed (golang.org/issue/7334). Except for the race detector bug, the liveness analysis check does not detect any problems (this CL and the previous CLs fixed all the detected problems). The net test still fails with GOGC=0 but the rest of the tests now pass or time out (because GOGC=0 is so slow). TBR=iant CC=golang-codereviews https://golang.org/cl/64170043
-
Rémy Oudompheng authored
The existing tests issue4463.go and issue4654.go had failures at typechecking and did not test walking the AST. Fixes #7272. LGTM=khr R=khr, rsc, iant CC=golang-codereviews https://golang.org/cl/60550044
-
Rob Pike authored
Catch the error instead and return it to the user. Before this fix, the template package panicked. Now you get: template: bug11:1:14: executing "bug11" at <.PS>: dereference of nil pointer of type *string Extended example at http://play.golang.org/p/uP6pCW3qKT Fixes #7333. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/64150043
-
- 14 Feb, 2014 18 commits
-
-
Anthony Martin authored
The branchtags method was removed but we should've been using branchmap all along. http://selenic.com/hg/rev/4274eda143cb LGTM=franciscossouza, r R=golang-codereviews, franciscossouza, r CC=golang-codereviews https://golang.org/cl/57500045
-
Adam Langley authored
These should never be found in a bzip2 file but it does appear that there's a buggy encoder that is producing them. Since the official bzip2 handles this case, this change makes the Go code do likewise. With this change, the code produces the same output as the official bzip2 code on the invalid example given in the bug. Fixes #7279. LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/64010043
-
David du Colombier authored
Rfork is not splitting the stack when creating a new thread, so the parent and child are executing on the same stack. However, if the parent returns and keeps executing before the child can read the arguments from the parent stack, the child will not see the right arguments. The solution is to load the needed pieces from the parent stack into register before INT $64. Thanks to Russ Cox for the explanation. LGTM=rsc R=rsc CC=ality, golang-codereviews https://golang.org/cl/64140043
-
Michael T. Jones authored
Fixes #7329 LGTM=gri R=gri, bradfitz, mtj CC=golang-codereviews https://golang.org/cl/63710043
-
Elias Naur authored
A previous CL added support for cross compiling with cgo, but missed the GOOS check in cmd/go. Remove it. Update #4714 LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/57210046
-
Ian Lance Taylor authored
Changing the PC confuses gdb, because execution does not continue where gdb expects it. Not changing the PC has the potential to confuse a stack dump, but when running under gdb it seems better to confuse a stack dump than to confuse gdb. Fixes #6776. LGTM=rsc R=golang-codereviews, dvyukov, rsc CC=golang-codereviews https://golang.org/cl/49580044
-
Mikio Hara authored
A configuration like the following: 7: tun6rd: <NOARP,UP,LOWER_UP> mtu 1280 link/sit 10.11.12.13 brd 0.0.0.0 inet 1.2.3.4/24 scope global tun6rd inet6 2014:1001:a0b:c0d::1/32 scope global inet6 ::10.11.12.13/128 scope global 9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1496 link/ppp inet 192.168.101.234 peer 192.168.102.234/32 scope global ppp0 inet 10.20.30.40/24 scope global ppp0 inet6 2014:1002::1/64 scope global 11: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 link/ipip 192.168.202.34 peer 192.168.202.69 inet 192.168.10.1/24 scope global tunnel0 inet6 2014:1003::1/64 scope global will be handled like below. "tun6rd": flags "up", ifindex 7, mtu 1280 hardware address "" interface address "1.2.3.4/24" interface address "2014:1001:a0b:c0d::1/32" interface address "::a0b:c0d/128" "ppp0": flags "up|pointtopoint|multicast", ifindex 9, mtu 1496 hardware address "" interface address "192.168.101.234/32" interface address "10.20.30.40/24" interface address "2014:1002::1/64" "tun0": flags "up|pointtopoint", ifindex 11, mtu 1480 hardware address "" interface address "192.168.10.1/24" interface address "2014:1003::1/64" Fixes #6433. Update #4839 LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/57700043
-
Mikio Hara authored
On Linux include/net directory is just to help porting applications from BSDs and files under net keep less information than include/linux. Making use of files under include/linux instead of include/net prevents lack of information. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/63930043
-
Dmitriy Vyukov authored
The following checkdead message is false positive: $ go test -race -c runtime $ ./runtime.test -test.cpu=2 -test.run=TestSmhasherWindowed -test.v === RUN TestSmhasherWindowed-2 checkdead: find g 18 in status 1 SIGABRT: abort PC=0x42bff1 LGTM=rsc R=golang-codereviews, gobot, rsc CC=golang-codereviews, iant, khr https://golang.org/cl/59490046
-
Dmitriy Vyukov authored
Currently small and large (size>rate) objects are merged into a single entry. But rate adjusting is required only for small objects. As a result pprof either incorrectly adjusts large objects or does not adjust small objects. With this change objects of different sizes are stored in different buckets. LGTM=rsc R=golang-codereviews, gobot, rsc CC=golang-codereviews https://golang.org/cl/59220049
-
Russ Cox authored
TBR=iant CC=golang-codereviews https://golang.org/cl/63680045
-
Shenghou Ma authored
It's implementation detail. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/63690043
-
Russ Cox authored
When the liveness code doesn't know a function doesn't return (but the generated code understands that), the liveness analysis invents a control flow edge that is not really there, which can cause variables to seem spuriously live. This is particularly bad when the variables are uninitialized. TBR=iant CC=golang-codereviews https://golang.org/cl/63720043
-
Dmitriy Vyukov authored
Currently it periodically fails with the following message. The immediate cause is the wrong base register when obtaining g in sys_windows_amd64/386.s. But there are several secondary problems as well. runtime: unknown pc 0x0 after stack split panic: invalid memory address or nil pointer dereference fatal error: panic during malloc [signal 0xc0000005 code=0x0 addr=0x60 pc=0x42267a] runtime stack: runtime.panic(0x7914c0, 0xc862af) c:/src/perfer/work/windows-amd64-a15f344a9efa/go/src/pkg/runtime/panic.c:217 +0x2c runtime: unexpected return pc for runtime.externalthreadhandler called from 0x0 R=rsc, alex.brainman CC=golang-codereviews https://golang.org/cl/63310043
-
Russ Cox authored
The registerization code needs the function to end in a RET, even if that RET is actually unreachable. The liveness code needs to avoid such unreachable RETs. It had a special case for final RET after JMP, but no case for final RET after UNDEF. Instead of expanding the special cases, let fixjmp - which already knows what is and is not reachable definitively - mark the unreachable RET so that the liveness code can identify it. TBR=iant CC=golang-codereviews https://golang.org/cl/63680043
-
Russ Cox authored
A normal RET is treated as using the return values, but a tail jump RET does not - it is jumping to the function that is going to fill in the return values. If a tail jump RET is recorded as using the return values, since nothing initializes them they will be marked as live on entry to the function, which is clearly wrong. Found and tested by the new code in plive.c that looks for variables that are incorrectly live on entry. That code is disabled for now because there are other cases remaining to be fixed. But once it is enabled, test/live1.go becomes a real test of this CL. TBR=iant CC=golang-codereviews https://golang.org/cl/63570045
-
Russ Cox authored
Any initialization of a variable by a block copy or block zeroing or by multiple assignments (componentwise copying or zeroing of a multiword variable) needs to emit a VARDEF. These cases were not. Fixes #7205. TBR=iant CC=golang-codereviews https://golang.org/cl/63650044
-
Russ Cox authored
The test added in CL 63630043 fails on 5g and 8g because they were not emitting the VARDEF instruction when clearing a fat value by clearing the components. 6g had the call in the right place. Hooray tests. TBR=iant CC=golang-codereviews https://golang.org/cl/63660043
-