- 24 Aug, 2018 5 commits
-
-
Tobias Klauser authored
Just open-code the fcntl syscall instead of relying on the obscurity of go:linkname. Change-Id: I3e4ec9db6539e016f56667d7b8b87aa37671d0e7 Reviewed-on: https://go-review.googlesource.com/130736 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Seebs authored
This message has no format specifiers and no trailing newline. It should use Println for consistency with other examples. Change-Id: I49bd1652f9449fcbdd79c6b689c123090972aab3 Reviewed-on: https://go-review.googlesource.com/127836Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
- add comments with builtin function signatures that are instantiated - use Nodes type from the beginning instead of []*Node with a later conversion to Nodes - use conv(x, y) helper function instead of nod(OCONV, x, y) - factor out repeated calls to Type.Elem() This makes the function style similar to newer functions like extendslice. passes toolstash -cmp Change-Id: Iedab191af9e0884fb6762c9c168430c1d2246979 Reviewed-on: https://go-review.googlesource.com/112598 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
A signed right shift before an unsigned right shift by register width-1 (extracts the sign bit) is superflous. trigger counts during ./make.bash 0 (Rsh8U (Rsh8 x _) 7 ) -> (Rsh8U x 7 ) 0 (Rsh16U (Rsh16 x _) 15 ) -> (Rsh16U x 15) 2 (Rsh32U (Rsh32 x _) 31 ) -> (Rsh32U x 31) 251 (Rsh64U (Rsh64 x _) 63 ) -> (Rsh64U x 63) Changes the instructions generated on AMD64 for x / 2 where x is a signed integer from: MOVQ AX, CX SARQ $63, AX SHRQ $63, AX ADDQ CX, AX SARQ $1, AX to: MOVQ AX, CX SHRQ $63, AX ADDQ CX, AX SARQ $1, AX Change-Id: I86321ae8fc9dc24b8fa9eb80aa5c7299eff8c9dc Reviewed-on: https://go-review.googlesource.com/115956 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Ben Shi authored
ARM64 also supports float point LDP(load pair) & STP (store pair). The CL adds implementation and corresponding test cases for FLDPD/FLDPS/FSTPD/FSTPS. Change-Id: I45f112012a4e097bfaf023d029b36e6cbc7a5859 Reviewed-on: https://go-review.googlesource.com/125438 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 23 Aug, 2018 11 commits
-
-
Dmitri Shuralyov authored
The wiki page has recently been created, and at this time it's just a stub. It's expected that support for WebAssembly will be evolving over time, and the wiki page can be kept updated with helpful information, how to get started, tips and tricks, etc. Use present tense because it's expected that there will be more general information added by the time Go 1.11 release happens. Also add link to https://webassembly.org/ in first paragraph. Change-Id: I139c2dcec8f0d7fd89401df38a3e12960946693f Reviewed-on: https://go-review.googlesource.com/131078Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Heschi Kreinick authored
gentraceback handles system stack transitions, but only when they're done by systemstack(). Handle morestack() too. I tried to do this generically but systemstack and morestack are actually *very* different functions. Most notably, systemstack returns "normally", just messes with $sp along the way. morestack never returns at all -- it calls newstack, and newstack then jumps both stacks and functions back to whoever called morestack. I couldn't think of a way to handle both of them generically. So don't. The current implementation does not include systemstack on the generated traceback. That's partly because I don't know how to find its stack frame reliably, and partly because the current structure of the code wants to do the transition before the call, not after. If we're willing to assume that morestack's stack frame is 0 size, this could probably be fixed. For posterity's sake, alternatives tried: - Have morestack put a dummy function into schedbuf, like systemstack does. This actually worked (see patchset 1) but more by a series of coincidences than by deliberate design. The biggest coincidence was that because morestack_switch was a RET and its stack was 0 size, it actually worked to jump back to it at the end of newstack -- it would just return to the caller of morestack. Way too subtle for me, and also a little slower than just jumping directly. - Put morestack's PC and SP into schedbuf, so that gentraceback could treat it like a normal function except for the changing SP. This was a terrible idea and caused newstack to reenter morestack in a completely unreasonable state. To make testing possible I did a small redesign of testCPUProfile to take a callback that defines how to check if the conditions pass to it are satisfied. This seemed better than making the syntax of the "need" strings even more complicated. Updates #25943 Change-Id: I9271a30a976f80a093a3d4d1c7e9ec226faf74b4 Reviewed-on: https://go-review.googlesource.com/126795 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Heschi Kreinick authored
gentraceback gets the currently running g to do some sanity checks, but should use gp everywhere to do its actual work. Some noncritical checks later accidentally used g instead of gp. This seems like it could be a problem in many different contexts, but I noticed in Windows profiling, where profilem calls gentraceback on a goroutine from a different thread. Change-Id: I3da27a43e833b257f6411ee6893bdece45a9323f Reviewed-on: https://go-review.googlesource.com/128895 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Michal Bohuslávek authored
This turns panic: function name is not a valid identifier into panic: function name "" is not a valid identifier and also makes it consistent with the func signature check. This CL also makes the testBadFuncName func a test helper. Change-Id: Id967cb61ac28228de81e1cd76a39f5195a5ebd11 Reviewed-on: https://go-review.googlesource.com/130998Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
We can no longer use the field's position for the duplicate field tag warning - since we now check embedded tags, the positions may belong to copmletely different packages. Instead, keep track of the lowest field that's still part of the top-level struct type that we are checking. Finally, be careful to not repeat the independent struct field warnings when checking fields again because they are embedded into another struct. To do this, separate the duplicate tag value logic into a func that recurses into embedded fields on a per-encoding basis. Fixes #25593. Change-Id: I3bd6e01306d8ec63c0314d25e3136d5e067a9517 Reviewed-on: https://go-review.googlesource.com/115677 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
-
Andrew Bonventre authored
Change-Id: I3f99083b7d8ab06482c2c22eafda8b0141a872bd Reviewed-on: https://go-review.googlesource.com/131076Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Kazuhiro Sera authored
Change-Id: Iadb3c5de8ae9ea45855013997ed70f7929a88661 GitHub-Last-Rev: ae85bcf82be8fee533e2b9901c6133921382c70a GitHub-Pull-Request: golang/go#26920 Reviewed-on: https://go-review.googlesource.com/128955Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
Like the conv helper function but for creating OCONVNOP nodes instead of OCONV nodes. passes toolstash -cmp Change-Id: Ib93ffe66590ebaa2b4fa552c81f1a2902e789d8e Reviewed-on: https://go-review.googlesource.com/112597 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Yury Smolsky authored
This CL adds the source code of all inlined functions into the function specified in $GOSSAFUNC. The code is appended to the sources column of ssa.html. ssaDumpInlined is populated with references to inlined functions. Then it is used for dumping the sources in buildssa. The source columns contains code in following order: target function, inlined functions sorted by filename, lineno. Fixes #25904 Change-Id: I4f6d4834376f1efdfda1f968a5335c0543ed36bc Reviewed-on: https://go-review.googlesource.com/126606 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Yury Smolsky authored
This CL exports the Func.Endlineno value for inlineable functions. It is needed to grab the source code of an imported function inlined into the function specified in $GOSSAFUNC. See CL 126606 for details. Updates #25904 Change-Id: I1e259e20445e4109b4621a95abb5bde1be457af1 Reviewed-on: https://go-review.googlesource.com/126605 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Yury Smolsky authored
Since we print almost everything to ssa.html in the GOSSAFUNC mode, there is a need to stop spamming stdout when user just wants to see ssa.html. This changes cleans output of the GOSSAFUNC debug mode. To enable the dump of the debug data to stdout, one must put suffix + after the function name like that: GOSSAFUNC=Foo+ Otherwise gc will not print the IR and ASM to stdout after each phase. AST IR is still sent to stdout because it is not included into ssa.html. It will be fixed in a separate change. The change adds printing out the full path to the ssa.html file. Updates #25942 Change-Id: I711e145e05f0443c7df5459ca528dced273a62ee Reviewed-on: https://go-review.googlesource.com/126603 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
- 22 Aug, 2018 24 commits
-
-
Oryan Moshe authored
The current implementation removes all of the optimization flags from the compiler. Added the -O0 optimization flag after the removal loop, so go can compile cgo on every OS consistently. Fixes #26487 Change-Id: Ia98bca90def186dfe10f50b1787c2f40d85533da Reviewed-on: https://go-review.googlesource.com/127755 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brian Kessler authored
The divLarge code contained "todo"s about avoiding alias and clear calls in the initialization of variables. By rearranging the order of initialization and always using an auxiliary variable for the shifted divisor, all of these calls can be safely avoided. On average, normalizing the divisor (shift>0) is required 31/32 or 63/64 of the time. If one always performs the shift into an auxiliary variable first, this avoids the need to check for aliasing of vIn in the output variables u and z. The remainder u is initialized via a left shift of uIn and thus needs no alias check against uIn. Since uIn and vIn were both used, z needs no alias checks except against u which is used for storage of the remainder. This change has a minimal impact on performance (see below), but cleans up the initialization code and eliminates the "todo"s. name old time/op new time/op delta Div/20/10-4 86.7ns ± 6% 85.7ns ± 5% ~ (p=0.841 n=5+5) Div/200/100-4 523ns ± 5% 502ns ± 3% -4.13% (p=0.024 n=5+5) Div/2000/1000-4 2.55µs ± 3% 2.59µs ± 5% ~ (p=0.548 n=5+5) Div/20000/10000-4 80.4µs ± 4% 80.0µs ± 2% ~ (p=1.000 n=5+5) Div/200000/100000-4 6.43ms ± 6% 6.35ms ± 4% ~ (p=0.548 n=5+5) Fixes #22928 Change-Id: I30d8498ef1cf8b69b0f827165c517bc25a5c32d7 Reviewed-on: https://go-review.googlesource.com/130775Reviewed-by: Robert Griesemer <gri@golang.org>
-
Iskander Sharipov authored
Use defined named constants instead of 0 literal in comparisons. Found using https://go-critic.github.io/overview.html#namedConst-ref Change-Id: Ic075cece248f6e51db0b3d9d9eaba7d6409c9eef Reviewed-on: https://go-review.googlesource.com/123376 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Iskander Sharipov authored
When this code was introduced, there were no R_MIPS, R_PPC64 and R_390 and build would fail with this code uncommented. Now we have those. Change-Id: I18a54eaa250db12e293f8e4d1f080f1dd2e66a4f Reviewed-on: https://go-review.googlesource.com/122896 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Change-Id: I7c9c83ba236e1050e04377a7591fef7174df698b Reviewed-on: https://go-review.googlesource.com/130415 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Emmanuel T Odeke authored
As reported in #26650 and also cautioned on the man page for fsync on OS X, fsync doesn't properly flush content to permanent storage, and might cause corruption of data if the OS crashes or if the drive loses power. Thus it is recommended to use the F_FULLFSYNC fcntl, which flushes all buffered data to permanent storage and is important for applications such as databases that require a strict ordering of writes. Also added a note in syscall_darwin.go that syscall.Fsync is not invoked for os.File.Sync. Fixes #26650. Change-Id: Idecd9adbbdd640b9c5b02e73b60ed254c98b48b6 Reviewed-on: https://go-review.googlesource.com/130676 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Dominik Honnef authored
This comment has been the source of much confusion and broken dreams. We can add it back if a tool ever gets released. Updates #16742 Change-Id: I4b9c179b7c60274e6ff1bcb607b82029dd9a893f Reviewed-on: https://go-review.googlesource.com/130876Reviewed-by: Matt Layher <mdlayher@gmail.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Zachary Amsden authored
If two goroutines are racing on a map, one of them will exit cleanly, clearing the hashWriting bit, and the other will likely notice and panic. If we use XOR instead of OR to set the bit in the first place, even numbers of racers will hopefully all see the bit cleared and panic simultaneously, giving the full set of available stacks. If a third racer sneaks in, we are no worse than the current code, and the generated code should be no more expensive. In practice, this catches most racing goroutines even in very tight races. See the demonstration program posted on https://github.com/golang/go/issues/26703 for an example. Fixes #26703 Change-Id: Idad17841a3127c24bd0a659b754734f70e307434 Reviewed-on: https://go-review.googlesource.com/126936 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Martin Möhrmann authored
Previously fmt would first obtain a list of map keys and then look up the value for each key. Since NaNs can be map keys but cannot be fetched directly, the lookup would fail and return a zero reflect.Value, which formats as <nil>. golang.org/cl/33572 added a map iterator to the reflect package that is used in this CL to retrieve the key and value from the map and prints the correct value even for keys that are not equal to themselves. Fixes #14427 Change-Id: I9e1522959760b3de8b7ecf7a6e67cd603339632a Reviewed-on: https://go-review.googlesource.com/129777Reviewed-by: Alan Donovan <adonovan@google.com>
-
Yury Smolsky authored
Also remove lineno from typecheckdeftype since copytype was the only user of it and typecheck uses lineno independently. toolstach-check passed. Updates #19683. Change-Id: I1663fdb8cf519d505cc087c8657dcbff3c8b1a0a Reviewed-on: https://go-review.googlesource.com/114875 Run-TryBot: Yury Smolsky <yury@smolsky.by> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Yury Smolsky authored
Store the value of GOSSAFUNC in a global variable to avoid multiple calls to os.Getenv from gc.buildssa and gc.mkinlcall1. The latter is implemented in the CL 126606. Updates #25942 Change-Id: I58caaef2fee23694d80dc5a561a2e809bf077fa4 Reviewed-on: https://go-review.googlesource.com/126604 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #27085 Change-Id: I4eb3ff7c76e0b8e4d8fe0298f739b0284d74a031 Reviewed-on: https://go-review.googlesource.com/130855Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
The Sqrt code previously used explicit constants for 2 and 1/2. This change replaces multiplication by these constants with increment and decrement of the floating point exponent directly. This improves performance by ~7-10% for small inputs and minimal improvement for large inputs. name old time/op new time/op delta FloatSqrt/64-4 1.39µs ± 0% 1.29µs ± 3% -7.01% (p=0.016 n=4+5) FloatSqrt/128-4 2.84µs ± 0% 2.60µs ± 1% -8.33% (p=0.008 n=5+5) FloatSqrt/256-4 3.24µs ± 1% 2.91µs ± 2% -10.00% (p=0.008 n=5+5) FloatSqrt/1000-4 7.42µs ± 1% 6.74µs ± 0% -9.16% (p=0.008 n=5+5) FloatSqrt/10000-4 65.9µs ± 1% 65.3µs ± 4% ~ (p=0.310 n=5+5) FloatSqrt/100000-4 1.57ms ± 8% 1.52ms ± 1% ~ (p=0.111 n=5+4) FloatSqrt/1000000-4 127ms ± 1% 126ms ± 1% ~ (p=0.690 n=5+5) Change-Id: Id81ac842a9d64981e001c4ca3ff129eebd227593 Reviewed-on: https://go-review.googlesource.com/130835Reviewed-by: Robert Griesemer <gri@golang.org>
-
Martin Möhrmann authored
This is causing failures on TryBots and BuildBots: --- FAIL: TestGcSys (0.06s) gc_test.go:27: expected "OK\n", but got "using too much memory: 39882752 bytes\n" FAIL Updates #27156 Change-Id: I418bbec89002574cd583c97422e433f042c07492 Reviewed-on: https://go-review.googlesource.com/130875 Run-TryBot: Martin Möhrmann <moehrmann@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alan Donovan authored
Example of use: iter := reflect.ValueOf(m).MapRange() for iter.Next() { k := iter.Key() v := iter.Value() ... } See issue golang/go#11104 Q. Are there any benchmarks that would exercise the new calls to copyval in existing code? Change-Id: Ic469fcab5f1d9d853e76225f89bde01ee1d36e7a Reviewed-on: https://go-review.googlesource.com/33572Reviewed-by: Keith Randall <khr@golang.org>
-
Yury Smolsky authored
This CL adds the "sources" column at the beginning of SSA table. This column displays the source code for the function being passed in the GOSSAFUNC env variable. Also UI was extended so that clicking on particular line will highlight all places this line is referenced. JS code was cleaned and formatted. This CL does not handle inlined functions. See issue 25904. Change-Id: Ic7833a0b05e38795f4cf090f3dc82abf62d97026 Reviewed-on: https://go-review.googlesource.com/119035 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Brad Fitzpatrick authored
I merged CL 115835 without testing it after a rebase. My bad. Change-Id: I0acc6ed78ea7d718ac2df11d509cfcf4364dfaee Reviewed-on: https://go-review.googlesource.com/130815 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
-
Iskander Sharipov authored
Replaces legacy Go syntax for pointer struct member access with more modern auto-deref alternative. Found using https://go-critic.github.io/overview#underef-ref Change-Id: I71a3c424126c4ff5d89f9e4bacb6cc01c6fa2ddf Reviewed-on: https://go-review.googlesource.com/122895 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Iskander Sharipov authored
Replace `x[:]` where x is a slice with just `x`. Found using https://go-critic.github.io/overview.html#unslice-ref Change-Id: Ib0ee16e1d49b2a875b6b92a770049acc33208362 Reviewed-on: https://go-review.googlesource.com/123375 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
The workthegc function was being inlined, and the slice did not escape, so there was no memory allocation. Use a sink variable to force memory allocation, at least for now. Fixes #23343 Change-Id: I02f4618e343c8b6cb552cb4e9f272e112785f7cf Reviewed-on: https://go-review.googlesource.com/122576 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Thanabodee Charoenpiriyakij authored
Fixes #26437 Change-Id: Id47b3bcc23ea7b7b17b55dd96b5830c48fd8d53d Reviewed-on: https://go-review.googlesource.com/124895Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Lynn Boger authored
The implementation of cputicks has been wrong for ppc64x. The previous code sequence is for 32 bit, not 64 bit. Change-Id: I308ae6cf9131f53a0100cd3f8ae4e16601f2d553 Reviewed-on: https://go-review.googlesource.com/129595 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Roland Illig authored
Fixes #26970 Change-Id: I0f2695434a53550cf84f702e9d8d02a37448d396 Reviewed-on: https://go-review.googlesource.com/129195Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Iskander Sharipov authored
Also adds some missing asmdecl comments for funcs with Go proto. Change-Id: Iabc68e8c0ad936e06ed719e0f030bfc5f6f6e168 Reviewed-on: https://go-review.googlesource.com/127760 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-