- 10 Jan, 2018 14 commits
-
-
Ian Lance Taylor authored
https://golang.org/cl/43970 changed writeOutputFunc to support niladic function-like macros; apply the corresponding change to writeGccgoOutputFunc. Updates #10715 Updates #18720 Change-Id: I5decb1d37ec71507466ade2eeda4b89c8785eaef Reviewed-on: https://go-review.googlesource.com/86475 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hiroshi Ioka <hirochachacha@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
GCC always recognizes the -fsplit-stack option, but then tests whether it is supported by the selected target. If not, it reports cc1: error: ‘-fsplit-stack’ is not supported by this compiler configuration Check for that error message when deciding whether a compiler option works. Change-Id: I2eef8d550bbecba3a087869df2c7351280c77290 Reviewed-on: https://go-review.googlesource.com/87136 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
We've had a series of problems with tests unexpectedly (and innocently) looking at system files that appear to (but don't) change in meaningful ways, like /dev/null on OS X having a modification time set to the current time. Cut all these off by only applying file change detection to the local package root: the GOROOT or specific sub-GOPATH in which the package being tested is found. (This means that if you test reads /tmp/x and you change /tmp/x, the cached result will still be used. Don't do that, or else use -count=1.) Fixes #23390. Change-Id: I30b6dd194835deb645a040aea5e6e4f68af09edb Reviewed-on: https://go-review.googlesource.com/87015 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
These were the last two occurences of exec.Command("go", ...) in all of std cmd. Checked with: gogrep '$(f is(func))("go", $*_)' std cmd Also changed lp_windows_test to use a test package name to avoid a circular dependency, since internal/testenv imports os/exec. Change-Id: I9a18948600dfecc8507ad76172e219e78b791ffd Reviewed-on: https://go-review.googlesource.com/87200 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Brad Fitzpatrick authored
Updates #17245 Change-Id: I3d7ea362809040fbbba4b33efd57bf2d27d4c390 Reviewed-on: https://go-review.googlesource.com/87257Reviewed-by:
-
Russ Cox authored
Fixes #23380. Change-Id: Ia9a086eada21b5561f110833afcf93e542a04407 Reviewed-on: https://go-review.googlesource.com/87175 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Fixes #23324. Change-Id: Ie2383bad35f0bcc1344a8a1683be08d5fd0eea96 Reviewed-on: https://go-review.googlesource.com/86977Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Than McIntosh authored
Given an inlinable method M in package P: func (r *MyStruct) M(...) { When M is compiled within its home package, the source position that the compiler records for 'r' (receiver parameter variable) is accurate, whereas if M is built as part of the compilation of some other package (body read from export data), the declaration line assigned to 'r' will be the line number of the 'import' directive, not the source line from M's source file. This inconsistency can cause differences in the size of abstract parameter DIEs (due to variable-length encoding), which can then in turn result in bad abstract origin offsets, which in turn triggers build failures on iOS (dsymutil crashes when it encounters an incorrect abstract origin reference). Work around the problem by removing the "declaration line number" attribute within the abstract parameter abbreviation table entry. The decl line attribute doesn't contribute a whole lot to the debugging experience, and it gets rid of the inconsistencies that trigger the dsymutil crashes. Updates #23374. Change-Id: I0fdc8e19a48db0ccd938ceadf85103936f89ce9f Reviewed-on: https://go-review.googlesource.com/87055 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Heschi Kreinick <heschi@google.com>
-
Samuel Tan authored
Ensure that we do not insert any escapers into pipelines that already contain an equivalent escaper. This prevents overescaping from occuring even when an aliased parse tree that has already been escaped is escaped again. Fixes #21844 Change-Id: Ic00d5e01c97ef09a4e49407009cf71b0d07f5c0e Reviewed-on: https://go-review.googlesource.com/83920Reviewed-by:
Russ Cox <rsc@golang.org>
-
kim yongbin authored
Change-Id: Ib5f5d20200284850c14c2431687bc102696ef8ae Reviewed-on: https://go-review.googlesource.com/87215Reviewed-by:
-
Ian Lance Taylor authored
Fixes #23150 Change-Id: Ia82c2d482a8dc53cabb3f173e4301fee66288821 Reviewed-on: https://go-review.googlesource.com/84376 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #23392 Change-Id: I5822b082b14d886b9c3b5ad7beebb2c01a77851b Reviewed-on: https://go-review.googlesource.com/87038 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Kunpei Sakai authored
Change-Id: I30e9b938bb19ed4e674c3ea4a1cd389b9c4f0b88 Reviewed-on: https://go-review.googlesource.com/86875Reviewed-by:
-
Russ Cox authored
Change-Id: I7be69a543841343a6ccbb335c7277009528fa0da Reviewed-on: https://go-review.googlesource.com/87024 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
- 09 Jan, 2018 13 commits
-
-
Russ Cox authored
There should not be a comma before "and" in the original text, because what follows is not a complete sentence. Rewrite. Change-Id: Ie99f204cc87e911fb46149e2eb65e132fa1eb63a Reviewed-on: https://go-review.googlesource.com/87020 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Robert Griesemer authored
Fixes #23389. Change-Id: Id6e86eebe44809db12a0e14014c474bf4fbf5108 Reviewed-on: https://go-review.googlesource.com/87035Reviewed-by:
-
Keith Randall authored
Fixes #23326 Change-Id: I6abc353ab004aadc6a4cbefbff3198f848640d7f Reviewed-on: https://go-review.googlesource.com/87036 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
All credit and blame goes to Ian for this suggestion, copied from the runtime. Fixes #23382 Updates #7921 Change-Id: I3d5a9ee4ab730c87e0f3feff3e7fceff9bcf9e18 Reviewed-on: https://go-review.googlesource.com/86976Reviewed-by:
-
Russ Cox authored
Type values being comparable implies that Type is a valid map key type. As previously written, they sound unrelated. Change-Id: I8e2235275d62898bfb47de850e8257b51ab5cbd6 Reviewed-on: https://go-review.googlesource.com/87021 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Change-Id: I20de6207d386635025dbb603c57219218e9a9af5 Reviewed-on: https://go-review.googlesource.com/87019 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Don't suggest that it's always necessary to disable optimizations. (The text can be misread that way, even if it's not what was meant.) Change-Id: I9a2dff6a75ce4a3f9210cdf4f5bad6aaaeae9b29 Reviewed-on: https://go-review.googlesource.com/87018 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
We were not being consistent. Standardize on toolchain. Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c Reviewed-on: https://go-review.googlesource.com/87017 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Change-Id: I3afaefc154f9ccfac353cedac7aefcfb70afe265 Reviewed-on: https://go-review.googlesource.com/86996 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Suppose you build the Go toolchain in directory A, move the whole thing to directory B, and then use it from B to build a new program hello.exe, and then run hello.exe, and hello.exe crashes with a stack trace into the standard library. Long ago, you'd have seen hello.exe print file names in the A directory tree, even though the files had moved to the B directory tree. About two years ago we changed the compiler to write down these files with the name "$GOROOT" (that literal string) instead of A, so that the final link from B could replace "$GOROOT" with B, so that hello.exe's crash would show the correct source file paths in the stack trace. (golang.org/cl/18200) Now suppose that you do the same thing but hello.exe doesn't crash: it prints fmt.Println(runtime.GOROOT()). And you run hello.exe after clearing $GOROOT from the environment. Long ago, you'd have seen hello.exe print A instead of B. Before this CL, you'd still see hello.exe print A instead of B. This case is the one instance where a moved toolchain still divulges its origin. Not anymore. After this CL, hello.exe will print B, because the linker sets runtime/internal/sys.DefaultGoroot with the effective GOROOT from link time. This makes the default result of runtime.GOROOT once again match the file names recorded in the binary, after two years of divergence. With that cleared up, we can reintroduce GOROOT into the link action ID and also reenable TestExecutableGOROOT/RelocatedExe. When $GOROOT_FINAL is set during link, it is used in preference to $GOROOT, as always, but it was easier to explain the behavior above without introducing that complication. Fixes #22155. Fixes #20284. Fixes #22475. Change-Id: Ifdaeb77fd4678fdb337cf59ee25b2cd873ec1016 Reviewed-on: https://go-review.googlesource.com/86835 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
The linker has been applying -X options before loading symbols, meaning that when it sees -X y=z it creates a symbol named y and initializes its string data to z. The symbol named y is marked "DUPOK" so that when the actual packages are loaded, no error is emitted when the real y is seen. The predefined y's data is used instead of whatever the real y says. If we define -X y=z and we never load y, then the predefined symbol is dropped during dead code elimination, but not in shared library builds. Shared library builds must include all symbols, so we have to be more careful about not defining symbols that wouldn't have appeared anyway. To be more careful, save the -X settings until after all the symbols are loaded from the packages, and then apply the string changes to whatever symbols are known (but ignore the ones that were not loaded at all). This ends up being simpler anyway, since it doesn't depend on DUPOK magic. Makes CL 86835 safe. Fixes #23273. Change-Id: Ib4c9b2d5eafa97c5a8114401dbec0134c76be54f Reviewed-on: https://go-review.googlesource.com/86915 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Samuel Tan authored
This reverts commit cd0a5f08, which unnecessarily restricts the use of AddParseTree. Change-Id: I1155214a20ba08981d604404e79fff54874fd8e4 Reviewed-on: https://go-review.googlesource.com/83919 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
When benchmarks run, they print lines like: BenchmarkGenericNoMatch-8 3000000 385 ns/op The first field, padded by spaces and followed by a tab, is printed when the benchmark begins running. The rest of the line is printed when the benchmark ends. Tools and people can watch the timing of these prints to see which benchmark is running. To allow tools consuming json output to continue to be able to see which benchmark is running, this CL adds a special case to the usual "line at a time" behavior to flush the benchmark name if it is observed separately from the rest of the line. Fixes #23352. Change-Id: I7b6410698d78034eec18745d7f57b7d8e9575dbb Reviewed-on: https://go-review.googlesource.com/86695 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 08 Jan, 2018 1 commit
-
-
Brad Fitzpatrick authored
Fixes #23372 Change-Id: Ie99fb4d84cb49efa66c0ff480d2656c33ef11e6d Reviewed-on: https://go-review.googlesource.com/86676Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 06 Jan, 2018 5 commits
-
-
Brad Fitzpatrick authored
Add Brad Burch (individual CLA) Add Charles Fenwick Elliott (individual CLA) Add Geoff Berry (corporate CLA for Qualcomm Data Center, Inc.) Add Igor Vashyst (individual CLA) Add Jiulong Wang (individual CLA) Add Junya Hayashi (individual CLA) Add Matthijs Kooijman (individual CLA) Add Paul PISCUC (individual CLA) Add Steve Gilbert (individual CLA) Add Tad Fisher (individual CLA) Add Yukihiro Nishinaka (individual CLA) Updates #12042 Change-Id: Ib7a3c7a4d38d15530c2ea42fe8d359ae10c9a19e Reviewed-on: https://go-review.googlesource.com/86478Reviewed-by:
-
Giovanni Bajo authored
Apple changed the format of its support page, so we need to restructure the HTML parser. The HTML table is now parsed using regular expressions, and certificates are then found in macOS trust store by their fingerprint. Fixes #22181 Change-Id: I29e7a40d37770bb005d728f1832299c528691f7e Reviewed-on: https://go-review.googlesource.com/77252 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
Brad Fitzpatrick authored
No longer needs to be done. Updates #23009 Updates #21255 Change-Id: I78e9e29a923dc03dea89ff3a5bf60f2e0bd0c0aa Reviewed-on: https://go-review.googlesource.com/86476Reviewed-by:
-
Brad Fitzpatrick authored
This reverts commit https://golang.org/cl/54030 Reason for revert: to not paint ourselves into a corner. See https://github.com/golang/go/issues/23009 Fixes #23009 Updates #21255 Change-Id: I68caab078839b9d2bf645a7bbed8405a5a30cd22 Reviewed-on: https://go-review.googlesource.com/86435Reviewed-by:
-
Brad Fitzpatrick authored
Updates #22018 Change-Id: I8a85324e9d53dd4d279ed05cdb93f50d55cf767b Reviewed-on: https://go-review.googlesource.com/86415Reviewed-by:
-
- 05 Jan, 2018 7 commits
-
-
Ian Lance Taylor authored
This just adds support on ELF systems, which is OK for now since that is all that gccgo works on. For the archive file generated by the compiler we add a new file _buildid.o that has a section .go.buildid containing the build ID. Using a new file lets us set the SHF_EXCLUDE bit in the section header, so the linker will discard the section. It would be nicer to use `objcopy --add-section`, but objcopy doesn't support setting the SHF_EXCLUDE bit. For an executable we just use an ordinary GNU build ID. Doing this required modifying cmd/internal/buildid to look for a GNU build ID, and use it if there is no other Go-specific note. This CL fixes a minor bug in gccgoTOolchain.link: it was using .Target instead of .built, so it failed for a cached file. This CL fixes a bug reading note segments: the notes are aligned as reported by the PT_NOTE's alignment field. Updates #22472 Change-Id: I4d9e9978ef060bafc5b9574d9af16d97c13f3102 Reviewed-on: https://go-review.googlesource.com/85555 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
If a benchmark calls b.Log without failing (without b.Error/b.Fatal/b.FailNow) then that turns into output very much like a test passing, except it says BENCH instead of PASS. Benchmarks failing say FAIL just like tests failing. Fixes #23346. Change-Id: Ib188e695952da78057ab4a13f90d49937aa3c232 Reviewed-on: https://go-review.googlesource.com/86396 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hana Kim authored
Fixes #23108 Change-Id: I9b3d0f0c399c0b4cb488adaf3c002bc55d5d21d9 Reviewed-on: https://go-review.googlesource.com/84795Reviewed-by:
-
Russ Cox authored
It is natural for tools to take a large string concatenation like "1" + "1" + "1" + ... + "1" and translate that into a sequence of go/constant calls: x := constant.MakeString("1") x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) x = constant.BinaryOp(x, token.ADD, constant.MakeString("1")) ... If the underlying representation of a string constant is a Go string, then this leads to O(N²) memory for the concatenation of N strings, allocating memory for "1", "11", "111", "1111", and so on. This makes go/types and in particular cmd/vet run out of memory (or at least use far too much) on machine-generated string concatenations, such as those generated by go-bindata. This CL allows code like the above to operate efficiently, by delaying the evaluation of the actual string constant value until it is needed. Now the representation of a string constant is either a string or an explicit addition expression. The addition expression is turned into a string the first time it is requested and then cached for future use. This slows down the use of single strings, but analyses are likely not dominated by that use anyway. It speeds up string concatenations, especially large ones, significantly. On my Mac running 32-bit code: name old time/op new time/op delta StringAdd/1-8 160ns ± 2% 183ns ± 1% +13.98% (p=0.000 n=10+10) StringAdd/4-8 650ns ± 1% 927ns ± 4% +42.73% (p=0.000 n=10+10) StringAdd/16-8 3.93µs ± 1% 2.78µs ± 2% -29.12% (p=0.000 n=8+9) StringAdd/64-8 37.3µs ± 9% 10.1µs ± 5% -73.06% (p=0.000 n=10+10) StringAdd/256-8 513µs ± 5% 38µs ± 1% -92.63% (p=0.000 n=10+10) StringAdd/1024-8 5.67ms ± 4% 0.14ms ± 2% -97.45% (p=0.000 n=8+10) StringAdd/4096-8 77.1ms ± 9% 0.7ms ± 2% -99.10% (p=0.000 n=10+9) StringAdd/16384-8 1.33s ± 7% 0.00s ±10% -99.64% (p=0.000 n=10+10) StringAdd/65536-8 21.5s ± 4% 0.0s ± 8% -99.89% (p=0.000 n=10+10) name old alloc/op new alloc/op delta StringAdd/1-8 232B ± 0% 256B ± 0% +10.34% (p=0.000 n=10+10) StringAdd/4-8 1.20kB ± 0% 1.24kB ± 0% +3.33% (p=0.000 n=10+10) StringAdd/16-8 14.7kB ± 0% 4.6kB ± 0% -68.87% (p=0.000 n=10+10) StringAdd/64-8 223kB ± 0% 16kB ± 0% -92.66% (p=0.000 n=10+10) StringAdd/256-8 3.48MB ± 0% 0.07MB ± 0% -98.07% (p=0.000 n=10+10) StringAdd/1024-8 55.7MB ± 0% 0.3MB ± 0% -99.53% (p=0.000 n=10+10) StringAdd/4096-8 855MB ± 0% 1MB ± 0% -99.88% (p=0.000 n=10+10) StringAdd/16384-8 13.5GB ± 0% 0.0GB ± 0% -99.97% (p=0.000 n=9+10) StringAdd/65536-8 215GB ± 0% 0GB ± 0% -99.99% (p=0.000 n=10+10) name old allocs/op new allocs/op delta StringAdd/1-8 3.00 ± 0% 3.00 ± 0% ~ (all equal) StringAdd/4-8 9.00 ± 0% 11.00 ± 0% +22.22% (p=0.000 n=10+10) StringAdd/16-8 33.0 ± 0% 25.0 ± 0% -24.24% (p=0.000 n=10+10) StringAdd/64-8 129 ± 0% 75 ± 0% -41.86% (p=0.000 n=10+10) StringAdd/256-8 513 ± 0% 269 ± 0% -47.56% (p=0.000 n=10+10) StringAdd/1024-8 2.05k ± 0% 1.04k ± 0% -49.29% (p=0.000 n=10+10) StringAdd/4096-8 8.19k ± 0% 4.12k ± 0% -49.77% (p=0.000 n=10+10) StringAdd/16384-8 32.8k ± 0% 16.4k ± 0% -49.97% (p=0.000 n=9+10) StringAdd/65536-8 131k ± 0% 66k ± 0% -50.11% (p=0.000 n=10+10) https://perf.golang.org/search?q=upload:20180105.2 Fixes #23348 (originally reported as cmd/vet failures in comments on #23222). This makes constant.Values of Kind String no longer meaningful for ==, which required fixes in go/types. While there, also fix go/types handling of constant.Values of Kind Int (for uint64), Float, and Complex. Change-Id: I80867bc9c4232c5c9b213443ff16645434a68b36 Reviewed-on: https://go-review.googlesource.com/86395 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
I marked every test that takes more than 0.5 seconds on my machine as something to run only when not in -short mode, or in -short mode on the beefy linux/amd64, windows/amd64, and darwin/amd64 builders. I also shortened a few needlessly-expensive tests where possible. Cuts the time for go test -short cmd/go from 45s to 15s on my machine. Should help even more on some of our builders and slower user machines. Fixes #23287. Change-Id: I0e36003ef947b0ebe4224a1373731f9fa9216843 Reviewed-on: https://go-review.googlesource.com/86252 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates #19943 Change-Id: Iea249be51a7af3264bee9ee2b28dbd91043275fc Reviewed-on: https://go-review.googlesource.com/86375Reviewed-by:
-
Brad Fitzpatrick authored
Also vendors x/net/http git rev 42fe2e1c for: http2: don't check WriteHeader status if we've already sent the header https://golang.org/cl/86255 Fixes #23010 Change-Id: I4f3dd63acb52d5a34a0350aaf847a7a376d6968f Reviewed-on: https://go-review.googlesource.com/86275Reviewed-by:
-
