- 08 Jun, 2017 8 commits
-
-
Robert Griesemer authored
For #14822. Change-Id: Ia3f5558f3e0dcb8ee2dab54a6e9588eecc22511f Reviewed-on: https://go-review.googlesource.com/45074Reviewed-by: Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
For non-constant shifts with an untyped constant shift count, the spec only said that it must "be converted to unsigned integer type". go/types accepts any (arbitrarily large) integer value. Both cmd/compile and gccgo require that the shift count be representable as a uint value in that case (if the shift count is typed, it may be any unsigned integer type). This change adjusts the spec to state what the compilers have been doing all along. The new wording matches similar rules elsewhere (e.g., for untyped array and slice indices). Also, while technically this is a restriction (we could permit arbitrarily large shift counts), in practice this is irrelevant. Fixes #14822. Change-Id: Ia75834c67483cf761c10025c8df758f225ef67c2 Reviewed-on: https://go-review.googlesource.com/45072Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Change-Id: I78c6198eb909e679cf0f776b77dda52211bfd347 Reviewed-on: https://go-review.googlesource.com/45133 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
The current implementation of "goroutine N cmd" assumes it can get goroutine N's state from the goroutine's sched buffer. But this only works if the goroutine is blocked. Extend find_goroutine so that, if there is no saved scheduler state for a goorutine, it tries to find the thread the goroutine is running on and use the thread's current register state. We also extend find_goroutine to understand saved syscall register state. Fixes #13887. Change-Id: I739008a8987471deaa4a9da918655e4042cf969b Reviewed-on: https://go-review.googlesource.com/45031 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Change-Id: I94aa87fe951701413b479c05b0bc8810255eb01c Reviewed-on: https://go-review.googlesource.com/45085 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Wei Xiao authored
TestBuildIDContainsArchModeEnv fails on arm64 because defaultGO386 has different value from x86 (amd64/386). On arm64 defaultGO386 = '387' but on x86 defaultGO386 = 'sse2'. The difference will make the test succeed on x86 while fail on arm64 since it generates the same build ID. Fix it by explicitly setting GO386 instead of using default value Fixes #20608 Change-Id: I864b0e47325942d9513516bdf47f60391d18c0d0 Reviewed-on: https://go-review.googlesource.com/45112Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Nigel Tao authored
Fixes #20597. Change-Id: Iaa059277c02e80a2fbef59cf8bb3c58d2b90fda0 Reviewed-on: https://go-review.googlesource.com/45111Reviewed-by: David Symonds <dsymonds@golang.org>
-
Ian Lance Taylor authored
Fixes #20541. Change-Id: Ifdfdf3616482b71761daf6d114b779a8ec532051 Reviewed-on: https://go-review.googlesource.com/44495 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
- 07 Jun, 2017 16 commits
-
-
Brad Fitzpatrick authored
Fixes #19850 Change-Id: I8c86e288159408c687c2a85f458ade282adae450 Reviewed-on: https://go-review.googlesource.com/45077 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joonas Kuorilehto authored
Remove note that sync.Cond, sync.Mutex, sync.RWMutex and atomic.Value can be created as part of other data structures. Structs can be embedded by default, and default should not be repeated. Fixes #20471. Change-Id: If3f5703d3f60abd96482b58ca43450d02a9e645a Reviewed-on: https://go-review.googlesource.com/44071Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Prep work for issues mentioned below. No semantic or functionality change. For #11945. For #17446. Change-Id: Ia1bb2b87647a6daa47f7863c0eb42cf5e1d35a7c Reviewed-on: https://go-review.googlesource.com/45076Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Alberto Donizetti authored
This change updates the vendored tzdata database to version 2017b (released 2017-03-20). The TestFirstZone test (which always uses the vendored database) is updated to make it work with the new timezones database. (The Tokelau abbreviation was changed from 'TKT' to the numeric abbreviation in tzdata-2017a) Fixes #19376 Change-Id: I0dea93e8703992de5c92c7840b8bacad9d02c50d Reviewed-on: https://go-review.googlesource.com/44832 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Fixes #20602. Change-Id: Iac1589484dec626c018314e0cea7efce091fd87d Reviewed-on: https://go-review.googlesource.com/45075Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Bulat Gaifullin authored
The Tx methods Query and Exec uses context.Background() even Tx was created by context. This patch enables using Tx.ctx in all Tx methods which do not has context arg. Backward compatibility: - If Tx has created without context, nothing changes. - If Tx has created with context and non-context method is called: - If context is expired, the execution fails, but it can fail on Commit or Rollback as well, so in terms of whole transaction - nothing changes. - If context is not expired, nothing changes too. Fixes #20098 Change-Id: I9570a2deaace5875bb4c5dcf7b3a084a6bcd0d00 Reviewed-on: https://go-review.googlesource.com/44956Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Daniel Theophanes <kardianos@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Phoenix authored
Change-Id: Ib5efe172c55ff624b6771c2f02c466e35ba6cc50 Reviewed-on: https://go-review.googlesource.com/45090Reviewed-by: Rob Pike <r@golang.org>
-
Alberto Donizetti authored
Updates #20587 Change-Id: I39f7c43a13c887d9d563c108d3575db7f2dffe0e Reviewed-on: https://go-review.googlesource.com/45050Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #20601 Change-Id: I296d50dc5210a735a2a65d64bfef05d14c93057b Reviewed-on: https://go-review.googlesource.com/45073 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rhys Hiltner <rhys@justin.tv> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
We insert guard instructions after each "dangerous" instruction to make NaCl's validator happy. This happens before asmout. If in asmout an instruction is split to two dangerous instructions, but only one guard instruction is inserted, the validation fails. Therefore don't split instructions on NaCl. Fixes #20595. Change-Id: Ie34f209bc7d907d6d16ecef6721f88420981ac01 Reviewed-on: https://go-review.googlesource.com/45021 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
The new math/bits package has a section for itself, and should not be mentioned in the 'Minor changes to the library' section of the release notes. Updates #20587 Change-Id: I13ecd35f5cee4324e50b2d31800e399c00159126 Reviewed-on: https://go-review.googlesource.com/45051Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates #20587 Change-Id: I5df603505ae1d4b65687bec1e973a4ab318b34f1 Reviewed-on: https://go-review.googlesource.com/45014Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Austin Clements authored
Currently the extra Ms created for cgo callbacks have a corresponding G that's kept in syscall state with only a call to goexit on its stack. This leads to confusing output from runtime.NumGoroutines and in tracebacks: goroutine 17 [syscall, locked to thread]: runtime.goexit() .../src/runtime/asm_amd64.s:2197 +0x1 Fix this by putting this goroutine into state _Gdead when it's not in use instead of _Gsyscall. To keep the goroutine counts correct, we also add one to sched.ngsys while the goroutine is in _Gdead. The effect of this is as if the goroutine simply doesn't exist when it's not in use. Fixes #16631. Fixes #16714. Change-Id: Ieae08a2febd4b3d00bef5c23fd6ca88fb2bb0087 Reviewed-on: https://go-review.googlesource.com/45030 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
The test is inherently racy, and for me fails about 0.05% of the time. So only fail the test if it fails ten times in a row. Fixes #20594 Change-Id: I3b3f7598f2196f7406f1a3937f38f21ff0c0e4b5 Reviewed-on: https://go-review.googlesource.com/45020 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
As motivated by https://golang.org/design/18130-type-alias which says: https://github.com/golang/proposal/blob/master/design/18130-type-alias.md#relationship-to-byte-and-rune > The language specification already defines byte as an alias for > uint8 and similarly rune as an alias for int32, using the word alias > as an informal term. It is a goal that the new type declaration > semantics not introduce a different meaning for alias. That is, it > should be possible to describe the existing meanings of byte and > uint8 by saying that they behave as if predefined by: > > type byte = uint8 > type rune = int32 So, do that. Seems to work. Updates #18130 Change-Id: I0740bab3f8fb23e946f3542fdbe819007a99465a Reviewed-on: https://go-review.googlesource.com/45017Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Update #20178 Change-Id: I603f77268ed38afdd84228c775efe006f08f14a7 Reviewed-on: https://go-review.googlesource.com/45018 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
- 06 Jun, 2017 11 commits
-
-
Ian Lance Taylor authored
For cgo programs on linux-amd64 we call the C function mmap. This supports programs such as the C memory sanitizer that need to intercept all calls to mmap. It turns out that there are programs that intercept both mmap and munmap, or that at least expect that if they intercept mmap, they also intercept munmap. So, if we permit mmap to be intercepted, also permit munmap to be intercepted. No test, as it requires two odd things: a C program that intercepts mmap and munmap, and a Go program that calls munmap. Change-Id: Iec33f47d59f70dbb7463fd12d30728c24cd4face Reviewed-on: https://go-review.googlesource.com/45016Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
Fixes #20591 Change-Id: I2a4674a3430c5a4d3c569f3ea654c6ff4d9bf7ee Reviewed-on: https://go-review.googlesource.com/45015Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Updates #18354. Change-Id: I76bc4a73d8dc99eeda14b395e451d75a65184191 Reviewed-on: https://go-review.googlesource.com/45013Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Keith Randall authored
Fixes #18331 Change-Id: Ie5c6685be3002533b84604ff1f13f2f0850f29e2 Reviewed-on: https://go-review.googlesource.com/45010 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Brad Fitzpatrick authored
Many TODOs remain. Updates #20587 Change-Id: If49854ae4d36346d9e072a386f413cc85c66b62a Reviewed-on: https://go-review.googlesource.com/45012Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
gulyasm authored
Go doesn't guarantee that the result of floating point operations will be the same on different architectures. It was not stated in the documentation, that can lead to confusion. Fixes #18354 Change-Id: Idb1b4c256fb9a7158a74256136eca3b8ce44476f Reviewed-on: https://go-review.googlesource.com/34938Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This allows reading from package storage systems that may not preserve the .a suffix (used with -importcfg). Fixes #20579 (combined with CLs earlier in stack). Change-Id: If2fc6a3d01bd0170a757e1f2ba9a22a4d9be7dbf Reviewed-on: https://go-review.googlesource.com/44853 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Adds the ability to specify the file location of each imported package, like in the -importcfg added to cmd/compile in a related CL. In effect, -importcfg is a generalization of and supersedes -installsuffix and -L. Of course, those flags will continue to be supported, for compatibility with other tools. Having this flag in Go 1.9 will let us try some experiments involving package management without needing guinea pigs to build a custom Go toolchain. This flag also helps with #14271 at some later point. For #20579. Change-Id: Ie4c171bcd3aa2faa446ac340e36516f2f9853882 Reviewed-on: https://go-review.googlesource.com/44851 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Allows reading -importmap options from a file instead of putting them all on the command line, and adds the ability to specify the file location of specific packages. In effect, -importcfg is a generalization of and supersedes -importmap, -importsuffix, and -I. Of course, those flags will continue to be supported, for compatibility with other tools. Having this flag in Go 1.9 will let us try some experiments involving package management without needing guinea pigs to build a custom Go toolchain. This flag also helps with #14271 at some later point. For #20579. Change-Id: If005dbc2b01d8fd16cbfd3687dfbe82499f4bc56 Reviewed-on: https://go-review.googlesource.com/44850 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #18991. Change-Id: I46ded007b0c6a6e1173a55f3938007ab3a928dd9 Reviewed-on: https://go-review.googlesource.com/44858 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Alberto Donizetti authored
Apparently people get confused by the fact that Split("", ",") returns []{""} instead of []{}. This is actually just a consequence of the fact that if the separator sep (2nd argument) is not found the string s (1st argument), then the Split* functions return a length 1 slice with the string s in it. Document the general case: if sep is not in s, what you get is a len 1 slice with s in it; unless both s and sep are "", in that case you get an empty slice of length 0. Fixes #19726 Change-Id: I64c8220b91acd1e5aa1cc1829199e0cd8c47c404 Reviewed-on: https://go-review.googlesource.com/44950Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
-
- 05 Jun, 2017 5 commits
-
-
Ian Lance Taylor authored
Try to avoid a race between the main goroutine exiting and a panic occurring. Don't try too hard, to avoid hanging. Updates #3934 Fixes #20018 Change-Id: I57a02b6d795d2a61f1cadd137ce097145280ece7 Reviewed-on: https://go-review.googlesource.com/41052Reviewed-by: Austin Clements <austin@google.com>
-
Alberto Donizetti authored
Make sure that in complex division we reject divisors that would underflow to zero when using the textbook complex-division method we currently use. This change does for go/types what golang.org/cl/42650 did for gc. Fixes #20227 Change-Id: Iaa784ac5e60141f51c501eb0e3ce0e9c1c2993d0 Reviewed-on: https://go-review.googlesource.com/44590 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
C code expects CR2, CR3, and CR4 to be preserved across function calls. Preserve the entire CR register across function calls in _rt0_ppc64le_linux_lib and crosscall2. The standard ppc64le call frame uses 8(R1) as the place to save CR; emulate that. It's hard to write a reliable test for this as it requires writing C code that sets CR2, CR3, or CR4 across a call to a Go function. Change-Id: If39e771a5b574602b848227312e83598fe74eab7 Reviewed-on: https://go-review.googlesource.com/44733 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
Ian Lance Taylor authored
The MOVFL instruction (which external PPC64 docs call mtcrf) can take either a CR register or a constant. It doesn't make sense to specify both, as the CR register implies the constant value. Specifying either a register or a constant is enforced by the implementation in the asmout method (case 69). However, the optab was providing a form that specified both a constant and a CR register, and was not providing a form that specified only a constant. This CL fixes the optab table to provide a form that takes only a constant. No test because I don't know where to write it. The next CL in this series will use the new instruction format. Change-Id: I8bb5d3ed60f483b54c341ce613931e126f7d7be6 Reviewed-on: https://go-review.googlesource.com/44732 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
Russ Cox authored
Programs built from N libraries required O(N²) time to do the deduplication checks, even if there were never any duplicates. In most programs N is small enough not to worry, but this may affect large programs. Noticed by inspection, not any specific bug report. Fixes #20578. Change-Id: Ic4108f1058be39da990a79b1e0b8ce95fde44cef Reviewed-on: https://go-review.googlesource.com/44852 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-