- 15 Jul, 2015 40 commits
-
-
Andrew Gerrand authored
Now that we care about the protocol of Git remotes (for the -insecure flag), we need to recognize and parse the SCP-like remote format. Fixes golang/go#11457 Change-Id: Ia26132274fafb1cbfefe2475f7ac5f17ccd6da40 Reviewed-on: https://go-review.googlesource.com/12226Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Running a safe-point function on syscall entry uses systemstack() and hence clobbers g.sched.pc and g.sched.sp. Fix this by re-saving them after the systemstack, just like in the other uses of systemstack in reentersyscall. Change-Id: I47868a53eba24d81919fda56ef6bbcf72f1f922e Reviewed-on: https://go-review.googlesource.com/12125Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently, we run a P's safe-point function immediately after entering _Psyscall state. This is unsafe, since as soon as we put the P in _Psyscall, we no longer control the P and another M may claim it. We'll still run the safe-point function only once (because doing so races on an atomic), but the P may no longer be at a safe-point when we do so. In particular, this means that the use of forEachP to dispose all P's gcw caches is unsafe. A P may enter a syscall, run the safe-point function, and dispose the P's gcw cache concurrently with another M claiming the P and attempting to use its gcw cache. If this happens, we may empty the gcw's workbuf after putting it on work.{full,partial}, or add pointers to it after putting it in work.empty. This will cause an assertion failure when we later pop the workbuf from the list and its object count is inconsistent with the list we got it from. Fix this by running the safe-point function just before putting the P in _Psyscall. Related to #11640. This probably fixes this issue, but while I'm able to show that we can enter a bad safe-point state as a result of this, I can't reproduce that specific failure. Change-Id: I6989c8ca7ef2a4a941ae1931e9a0748cbbb59434 Reviewed-on: https://go-review.googlesource.com/12124 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Change-Id: I945d46d3bb63f1992bce0d0b1e89e75cac9bbd54 Reviewed-on: https://go-review.googlesource.com/12271Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
There was already special code to recognize "?" in hidden_structdcl, which is used for inlined types and variables. This recognizes "?" in structdcl as well, a case that arises when a struct type appears within an inlined function body. Fixes #10219. Change-Id: Ic5257ae54f817e0d4a189c2294dcd633c9f2101a Reviewed-on: https://go-review.googlesource.com/12241 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #8837. Change-Id: Iaaecbb0b324004cb74b16b764126b01315e6a16e Reviewed-on: https://go-review.googlesource.com/12209Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Rob Pike authored
The parser treats (R1+R2) on ppc64 the same as (R1,R2) on arm, but it is not strictly a "register pair". Improve the text. No semantic change. Change-Id: Ib8b14881c6467add0d53150a901c01e962afb28b Reviewed-on: https://go-review.googlesource.com/12212Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
For #9880. Let's see what breaks. Change-Id: Ic8b99a604e60177a448af5f7173595feed607875 Reviewed-on: https://go-review.googlesource.com/10818Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
-
Russ Cox authored
Fixes #8427. Change-Id: I826a3bc4519845ad30d6dbaf058fe7ed7bee8db0 Reviewed-on: https://go-review.googlesource.com/12233Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
- Make Log2 exact for powers of two. - Fix error tolerance function to make tolerance a function of the correct (expected) value. Fixes #9066. Change-Id: I0320a93ce4130deed1c7b7685627d51acb7bc56d Reviewed-on: https://go-review.googlesource.com/12230Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #9650. Change-Id: I45b879124691e485b86c1e99a3227032283850d2 Reviewed-on: https://go-review.googlesource.com/12208Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #9140. Change-Id: I3b85053262cac3c30358f8e03a5aca65dbc67623 Reviewed-on: https://go-review.googlesource.com/12231Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Originally 'go test -h' printed the output of 'go help test'. Then issue #6576 was filed, because that output didn't list (for example) -bench. CL 14502065 changed 'go test -h' to print the output of 'go help testflag'. Then issue #9209 was filed, because that output didn't list (for example) -c. To print all the relevant flags, parts of both 'go help test' and 'go help testflag' are needed. Refactor the help messages to make those parts available and print them. Fixes #9209. Change-Id: Ie8205b8fb37d00c10d25b3fc98f14286ec46c4e3 Reviewed-on: https://go-review.googlesource.com/12173Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #10731. Change-Id: I105629b03fd3323c0a2ca5b6b0fd35ee92b7fd2e Reviewed-on: https://go-review.googlesource.com/12146Reviewed-by: Rob Pike <r@golang.org>
-
Nigel Tao authored
Before, calling the RGBA method of YCbCr color would return red values in the range [0x0080, 0xff80]. After, the range is [0x0000, 0xffff] and is consistent with what Gray colors' RGBA method returns. In particular, pure black, pure white and every Gray color in between are now exactly representable as a YCbCr color. This fixes a regression from Go 1.4 (where YCbCr{0x00, 0x80, 0x80} was no longer equivalent to pure black), introduced by golang.org/cl/8073 in the Go 1.5 development cycle. In Go 1.4, the +0x80 rounding was not noticable when Cb == 0x80 && Cr == 0x80, because the YCbCr to RGBA conversion truncated to 8 bits before multiplying by 0x101, so the output range was [0x0000, 0xffff]. The TestYCbCrRoundtrip fuzzy-match tolerance grows from 1 to 2 because the YCbCr to RGB conversion now maps to an ever-so-slightly larger range, along with the usual imprecision of accumulating rounding errors. Also s/int/int32/ in ycbcr.go. The conversion shouldn't overflow either way, as int is always at least 32 bits, but it does make it clearer that the computation doesn't depend on sizeof(int). Fixes #11691 Change-Id: I538ca0adf7e040fa96c5bc8b3aef4454535126b9 Reviewed-on: https://go-review.googlesource.com/12220Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Change-Id: I0f167d9769d9b6b9888c13fcb48e538fc87aa1b7 Reviewed-on: https://go-review.googlesource.com/12240Reviewed-by: Russ Cox <rsc@golang.org>
-
Rob Pike authored
Fixes #10963. Change-Id: I8d769b4d25b306f2df41f882ec01d97bbd63171d Reviewed-on: https://go-review.googlesource.com/12221Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #10338. Change-Id: Ib86cb9a6c694b1e442a9957153c7ca38a7d11c3e Reviewed-on: https://go-review.googlesource.com/12232Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #9427. Change-Id: If8094d4d4f6737c03d83e08e177c2a7f0ff9d89f Reviewed-on: https://go-review.googlesource.com/12234Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #3652. (Well, already fixed, but tests that it stays fixed.) Change-Id: I4e17f595ee2ad513de86ac3861e8e66b1230b3be Reviewed-on: https://go-review.googlesource.com/12195Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Failures noted by dashboard. Change-Id: I22f90120c6687b64b9efff9df7a7fa8f26d24bac Reviewed-on: https://go-review.googlesource.com/12207Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #9357. Change-Id: I11f0652758c4ea80debec29c3b99a72baca6d745 Reviewed-on: https://go-review.googlesource.com/12193Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #9224. Change-Id: Ie0f4f14407099e4fa7ebe361a95b6492012928a2 Reviewed-on: https://go-review.googlesource.com/12192Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This fix only works on Git 2.3.0 and later. There appears to be no portable way to fix the earlier versions. We already run git with stdin closed, but on Unix git calls getpass, which opens /dev/tty itself. We could do package syscall-specific things to get /dev/tty invalidated during the exec, but I'd really rather not. And on Windows, Git opens "CONIN$" and "CONOUT$" itself, and I have no idea how to invalidate those. Fix the problem for newish Git versions and wait for people to update. Best we can do. Fixes #9341. Change-Id: I576579b106764029853e0f74d411e19108deecf5 Reviewed-on: https://go-review.googlesource.com/12175Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #8952. Change-Id: I678f9706eccb5a344eeb0244f45b7b7669830bdc Reviewed-on: https://go-review.googlesource.com/12204Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #9146. Change-Id: If5cb5ae92a201825b9ff32b3d0edfa032b9a0965 Reviewed-on: https://go-review.googlesource.com/12203Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #9180. Change-Id: Id5adaea0ca9005946fb89c88a10c6f59d8c0943c Reviewed-on: https://go-review.googlesource.com/12202Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #10259. Change-Id: Ica6b8301cc8291785a3c496fb513050813b2d8df Reviewed-on: https://go-review.googlesource.com/12201Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #11305. Change-Id: Icaa3a009aa4ab214c9aaf74f52c3e622fa266a9d Reviewed-on: https://go-review.googlesource.com/12194Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #11090. Change-Id: I1518df7a48346b175ec80079a07225901fdd51fb Reviewed-on: https://go-review.googlesource.com/12177Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #9558. Change-Id: I68506af58088155d38d492b49b19c5fc2048b087 Reviewed-on: https://go-review.googlesource.com/12176Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fix now uses same test as 'go build'. Fixes #10500. Change-Id: I2fcf2d95430643370aa29165d89a188988dee446 Reviewed-on: https://go-review.googlesource.com/12174Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Also use more consistent language for the new build options. Change-Id: I88cbe200c13f452713be73d2e00337ddb793b8c6 Reviewed-on: https://go-review.googlesource.com/12172Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #10210. Change-Id: I82ddd665bca31773b1fb1b056338c04818ef68f5 Reviewed-on: https://go-review.googlesource.com/12171Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Also adds to 'go test' all the build flags that were missing due to inconsistency in the duplication (for example, -toolexec). Fixes #10504. Change-Id: I1935b5caa13d5e551a0483904adffa8877087df7 Reviewed-on: https://go-review.googlesource.com/12170Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #9853. Change-Id: Ic4803aa499ca20215085a87bad649014984d84c8 Reviewed-on: https://go-review.googlesource.com/12149Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
While we are here, fix a few things not updated for -insecure. Fixes #8163. Change-Id: Ib80c9ac00d6b61cce26c3d20bee3d30ab9af1331 Reviewed-on: https://go-review.googlesource.com/12148Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Was detecting only non-trivial ones. Fixes #9690. Change-Id: I662d81dd4818ddf29592057c090805772c84287b Reviewed-on: https://go-review.googlesource.com/12147Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
This reverts commit 3b411bf1a1bb08d6868083981cecba8088dc7aea. Change-Id: I321a43fa378a43b3e4d7aa97e0222775640af64b Reviewed-on: https://go-review.googlesource.com/12205Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
These used to be defined at use, but that breaks when shared libraries are involved. For #11480. Change-Id: I416a848754fb615c0d75f9f0ccc00723d07f7f01 Reviewed-on: https://go-review.googlesource.com/12145Reviewed-by: Rob Pike <r@golang.org>
-