Select linux/arm64 for the asm test.
Disable the cgo test for now.
Will fix properly in a follow-up.
Filed Issue 28829 to track it.
Updates #28829
Change-Id: Ic05f619700b06e91c43f8c150b089b8e77d92c85
Reviewed-on: https://go-review.googlesource.com/c/149937
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On reflect documentation page only this function
doesn't have description, this commit add simple description.
Change-Id: Idcda89ddd1f6fdd1938c4030e89ebdc186255ce6
GitHub-Last-Rev: 1553b834bb
GitHub-Pull-Request: golang/go#28818
Reviewed-on: https://go-review.googlesource.com/c/149721
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 129682 removed go mod fix but unfortunately
we hadn't updated the source code hence running
go mod -fix
would suggest
go mod fix
which is a nonexistent command.
This change fixes that to instead suggest
go mod tidy
Change-Id: Ie0d7c90805034e9fe6df24afaa15340c44d4f426
GitHub-Last-Rev: 5ae1340954
GitHub-Pull-Request: golang/go#28402
Reviewed-on: https://go-review.googlesource.com/c/144838
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change deletes the legacy implementation of vet, replacing it
with a short main.go that merely selects the desired analyzers and
calls into the "unitchecker" implementation vendored from
golang.org/x/tools/go/analysis.
Unlike the full vet checker (x/tools/go/analysis/cmd/vet), the 'lite'
unitchecker cannot also be run standalone (as 'go tool vet' or
cmd/vet); it must be invoked by 'go vet'.
This design was chosen to avoid vendoring many
additional dependencies into GOROOT, in particular go/packages. If
go/packages should someday become part of the standard library, there
will be considerable opportunity for simplification.
This change also patches the vendored analysisflag package
(by adding patch.go) so that it fully supports the build
system's -V flag protocol.
Also:
- remove stale internal/unitchecker/ tree
(belonged in https://go-review.googlesource.com/c/149778).
- move vet legacy flags (-all, -v, -source, -tags) into analysisflags
as all drivers will need them, not just unitchecker.
I will upstream this change.
A sampling of tests from the cmd/vet testsuite have been preserved as
a smoke test, to ensure that each analyzer is being run, and for
convenience when evaluating changes. Comprehensive tests for each
analyzer live upstream in x/tools. The tests have been heavily reduced
and reorganized so that they conform to the structure required by 'go
vet'.
Change-Id: I84b38caeef733e65deb95234b3b87b5f61046def
Reviewed-on: https://go-review.googlesource.com/c/149609
Reviewed-by: Russ Cox <rsc@golang.org>
The old whole-page reclaimer was the only thing that used the busy
span lists. Remove them so nothing uses them any more.
Change-Id: I4007dd2be08b9ef41bfdb0c387215c73c392cc4c
Reviewed-on: https://go-review.googlesource.com/c/138960
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When we attempt to allocate an N page span (either for a large
allocation or when an mcentral runs dry), we first try to sweep spans
to release N pages. Currently, this can be extremely expensive:
sweeping a span to emptiness is the hardest thing to ask for and the
sweeper generally doesn't know where to even look for potentially
fruitful results. Since this is on the critical path of many
allocations, this is unfortunate.
This CL changes how we reclaim empty spans. Instead of trying lots of
spans and hoping for the best, it uses the newly introduced span marks
to efficiently find empty spans. The span marks (and in-use bits) are
in a dense bitmap, so these spans can be found with an efficient
sequential memory scan. This approach can scan for unmarked spans at
about 300 GB/ms and can free unmarked spans at about 32 MB/ms. We
could probably significantly improve the rate at which is can free
unmarked spans, but that's a separate issue.
Like the current reclaimer, this is still linear in the number of
spans that are swept, but the constant factor is now so vanishingly
small that it doesn't matter.
The benchmark in #18155 demonstrates both significant page reclaiming
delays, and object reclaiming delays. With "-retain-count=20000000
-preallocate=true -loop-count=3", the benchmark demonstrates several
page reclaiming delays on the order of 40ms. After this change, the
page reclaims are insignificant. The longest sweeps are still ~150ms,
but are object reclaiming delays. We'll address those in the next
several CLs.
Updates #18155.
Fixes#21378 by completely replacing the logic that had that bug.
Change-Id: Iad80eec11d7fc262d02c8f0761ac6998425c4064
Reviewed-on: https://go-review.googlesource.com/c/138959
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This adds a bitmap indexed by page number that marks the starts of
in-use spans. This will be used to quickly find in-use spans with no
marked objects for sweeping.
For #18155.
Change-Id: Icee56f029cde502447193e136fa54a74c74326dd
Reviewed-on: https://go-review.googlesource.com/c/138957
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, there's no efficient way to iterate over the Go heap. We're
going to need this for fast free page sweeping, so this CL adds a
slice of all allocated heap arenas. This will also be useful for
generational GC.
For #18155.
Change-Id: I58d126cfb9c3f61b3125d80b74ccb1b2169efbcc
Reviewed-on: https://go-review.googlesource.com/c/138076
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
cmd/vet/all applies vet to all packages in the standard tree.
It is run for every configuration using this command:
GO_BUILDER_NAME=misc-vetall go tool dist test
by the misc-vetall builder (see chart at build.golang.org).
Ideally we would switch to 'go vet', but it effectively does a partial
build. This means that its analysis has accurate type information, so
it reports slightly fewer spurious diagnostics. However, it is more
than twice as slow.
Instead, cmd/vet/all builds and runs
golang.org/x/tools/go/analysis/cmd/vet, which uses x/tools/go/packages
to load the entire std lib from source. It takes about 4min to run all
OS/ARCH pairs. An important consequence is that golang.org/x/tools
must be on your $GOPATH to run cmd/vet/all. The test has been
temporarily modified to warn and skip if this is not the case.
This is a preparatory step for switching to the new
cmd/vet based on vet-lite.
Whitelist changes:
- The two "deadcode" diagnostics removed from the whitelist were due
to if-conditions that could now be proven false.
- The asmdecl warnings are now printed with the log.Printf prefix,
so they are discarded by the parser and needn't be whitelisted.
Change-Id: I6486508b0de2cd947c897523af086a408cbaf4a8
Reviewed-on: https://go-review.googlesource.com/c/149097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Starting with 1.12, we must use syscall versions
of sysctl instead of the raw syscall.
An identical CL went into the source copy at golang.org/x/net/route.
This is just a cherry pick of that CL.
(CL: https://go-review.googlesource.com/c/net/+/148597)
Change-Id: I6286ab3e49f82512491afb5bcf349e89ab5645ab
Reviewed-on: https://go-review.googlesource.com/c/149637
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When CL 147160 introduced function ABIs encoded as symbol versions in
the linker, it became slightly more complicated to look up derived
DWARF symbols. It fixed this by introducing a dwarfFuncSym function to
hide this logic, but missed one derived lookup that was done in the
object reader itself. As a result, we lost the isStmt tables from the
compiler, so every PC was marked as a statement in the DWARF info.
Fix this by moving this derived lookup out of the object reader and
into the DWARF code and calling dwarfFuncSym to get the correctly
versioned symbol.
Should fix the linux-amd64-longtest builder.
Updates #27539.
Change-Id: If40d5ba28bab1918ac4ad18fbb5103666b6d978b
Reviewed-on: https://go-review.googlesource.com/c/149605
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Change internal/cpu feature configuration to use
GODEBUG=cpu.feature1=value,cpu.feature2=value...
instead of GODEBUGCPU=feature1=value,feature2=value... .
This is not a backwards compatibility breaking change
since GODEBUGCPU was introduced in go1.11 as an
undocumented compiler experiment.
Fixes#28757
Change-Id: Ib21b3fed2334baeeb061a722ab1eb513d1137e87
Reviewed-on: https://go-review.googlesource.com/c/149578
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I've never seen a case where unsafe arithmetic is used to generate a nil.
(Something like var x uintptr; unsafe.Pointer(x - x).)
We can assume that if someone is doing arithmetic with pointers, the
result will be non-nil. Our unsafe rules already forbid this, although
we should be more explicit.
RELNOTE=It is invalid to convert a nil unsafe.Pointer to uintptr and back, with arithmetic.
(This was already invalid, but this statement has been added for clarification.)
Fixes#27180
Change-Id: I1880b7725a9fd99e4613799930fdad9aaa99e8f0
Reviewed-on: https://go-review.googlesource.com/c/146058
Reviewed-by: Austin Clements <austin@google.com>
This allows one to customize which ar to use by fetching its path
from the environment. This way one can swap it out for a
different implementation.
Change-Id: I40d8cbd8a69e97b5254e66081d9bf0b726c10366
GitHub-Last-Rev: 4aa1d631ea
GitHub-Pull-Request: golang/go#28746
Reviewed-on: https://go-review.googlesource.com/c/149117
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
fmtBytes is in the top 10 callers of runtime.slicebytetostring according
to Google wide profiling data.
Avoid the string conversion of the input byte slice in fmtBytes by calling
a newly added specialized fmtS function for byte slices.
Expand tests for verb s with widths to test strings and byte slice arguments.
SprintfTruncateString 157ns ± 4% 156ns ± 3% ~ (p=0.122 n=20+20)
SprintfTruncateBytes 188ns ± 2% 155ns ± 3% -18.00% (p=0.000 n=20+19)
name old alloc/op new alloc/op delta
SprintfTruncateString 16.0B ± 0% 16.0B ± 0% ~ (all equal)
SprintfTruncateBytes 64.0B ± 0% 16.0B ± 0% -75.00% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
SprintfTruncateString 1.00 ± 0% 1.00 ± 0% ~ (all equal)
SprintfTruncateBytes 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=20+20)
Change-Id: I461bf514d4232b39bd9c812f7faa4e5ef693a03b
Reviewed-on: https://go-review.googlesource.com/c/145284
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The current support_XXX variables are specific for the
amd64 and 386 platforms.
Prefix processor capability variables by architecture to have a
consistent naming scheme and avoid reuse of the existing
variables for new platforms.
This also aligns naming of runtime variables closer with internal/cpu
processor capability variable names.
Change-Id: I3eabb29a03874678851376185d3a62e73c1aff1d
Reviewed-on: https://go-review.googlesource.com/c/91435
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Given a nonexistent directory above a wildcard:
go run ./nonexistent/...
Print this error instead of panicking:
go run: no packages loaded from ./nonexistent/...
Fixes#28696.
Change-Id: Iaa3bc5c78b14ef858d931778e1bc55ca626c5571
GitHub-Last-Rev: bb1a80483a
GitHub-Pull-Request: golang/go#28703
Reviewed-on: https://go-review.googlesource.com/c/148821
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
When using soft-float, OMUL might be rewritten to function call
so we should ensure it was evaluated first.
Fixes#28688
Change-Id: I30b87501782fff62d35151f394a1c22b0d490c6c
Reviewed-on: https://go-review.googlesource.com/c/148837
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add GOOS=linux to vet_asm script to avoid errors on OS not working on
amd64 architecture.
Change-Id: Ic3db43618008ae8e8bc08738c95c200dd4e916d7
Reviewed-on: https://go-review.googlesource.com/c/149577
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Move the empty header file created by "builddir", "buildrundir"
directives to t.tempDir. The file was accidentally placed in the
same directory as the source code and this was a vestige of CL 146999.
Fixes#28781
Change-Id: I3d2ada5f9e8bf4ce4f015b9bd379b311592fe3ce
Reviewed-on: https://go-review.googlesource.com/c/149458
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The bootstrap stage 1 compiler was defaulting to the language version
used by the bootstrap compiler itself, typically 1.4. Normally this
doesn't matter since the bootstrap code has to build with 1.4 anyhow,
but it broke the boringcrypto branch which uses cgo during the
bootstrap, as cgo now generates code that uses type aliases.
Change-Id: I8a8312bb9ca4befaf65c00a8d71a78566075c2f7
Reviewed-on: https://go-review.googlesource.com/c/149459
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Because run.go doesn't pass the package being compiled to the compiler
via the -p flag, it can't match up the main·f symbol from the
assembler with the "func f" stub in Go, so it doesn't produce the
correct assembly stub.
Fix this by removing the package prefix from the assembly definition.
Alternatively, we could make run.go pass -p to the compiler, but it's
nicer to remove these package prefixes anyway.
Should fix the linux-arm builder, which was broken by the introduction
of function ABIs in CL 147160.
Updates #27539.
Change-Id: Id62b7701e1108a21a5ad48ffdb5dad4356c273a6
Reviewed-on: https://go-review.googlesource.com/c/149483
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When we set an explicit argmap, we may want only a prefix of that
argmap. Argmap is set when the function is reflect.makeFuncStub or
reflect.methodValueCall. In this case, arglen specifies how much of
the args section is actually live. (It could be either all the args +
results, or just the args.)
Fixes#28750
Change-Id: Idf060607f15a298ac591016994e58e22f7f92d83
Reviewed-on: https://go-review.googlesource.com/c/149217
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When we delete an element, and it was the last element in the bucket,
update the slots between the new last element and the old last element
with the marker that says "no more elements beyond here".
Change-Id: I8efeeddf4c9b9fc491c678f84220a5a5094c9c76
Reviewed-on: https://go-review.googlesource.com/c/142438
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that vet can rely on go/types, there's no reason to do extra work to
avoid using it. The rewrite lets us get rid of the field list flattening
code, as well as the slight verbosity that comes with go/printer.
While at it, make the testdata/method.go expected errors be more
specific, to make sure that we're not breaking the warnings that are
printed.
Finally, update whitelist/all.txt, since the reported errors now include
qualified types.
Change-Id: I760a1b3b1f60e4a478c9dc43bd7f584a8459593e
Reviewed-on: https://go-review.googlesource.com/c/148919
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Alan Donovan <adonovan@google.com>
When module is enabled, the go tool embeds build information
related to the module in the binary including the dependencies
and the replace information (See
src/cmd/go/internal/modload.PackageBuildInfo).
The newly introduced ReadBuildInfo reads the information and
makes it accessible programmatically.
Update #26404
Change-Id: Ide37022d609b4a8fb6b5ce02afabb73f04fbb532
Reviewed-on: https://go-review.googlesource.com/c/144220
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Changes include:
1. enable compiler option -race for arm64
2. add runtime/race_arm64.s to manage the calls from Go to the compiler-rt runtime
3. change racewalk.go to call racefuncenterfp instead of racefuncenter on arm64 to
allow the caller pc to be obtained in the asm code before calling the tsan version
4. race_linux_arm64.syso comes from compiler-rt which just supports 48bit VA, compiler-rt
is fetched from master branch which latest commit is 3aa2b775d08f903f804246af10b
Fixes#25682
Change-Id: I04364c580b8157fd117deecae74a4656ba16e005
Reviewed-on: https://go-review.googlesource.com/c/138675
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The "gofiles" cache entry has been renamed "srcfiles", and it includes
non-Go files (.s, .c, .cxx) that belong to the package. It does not
include raw cgo files.
Added regression test.
Fixes#27665
Change-Id: I4884fe9b4f823f50705f8c2d357a04a8e567734f
Reviewed-on: https://go-review.googlesource.com/c/148904
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I see no reason Plan 9 should be special cased.
A directory named go.mod is not useful on any system.
Followup to CL 129804.
Change-Id: I9cc91b5934b17650bfdb07370aa73aeae445968c
Reviewed-on: https://go-review.googlesource.com/c/149337
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The code to implement new-style gccgo name mangling had a recipe that
didn't quite match that of the compiler (incorrect handling for '.').
This showed up as a failure in the gotools cgo test if the directory
containing the test run included a "." character.
[This is a copy of https://golang.org/cl/147917].
Change-Id: Ia94728ecead879c8d223eb6cee6c102a8af1c86e
Reviewed-on: https://go-review.googlesource.com/c/147937
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts CL 144137.
Reason for revert: The justification for the original commit
was that golint said so, but golint is wrong. The code reads
more clearly the original way.
Change-Id: I960f286ed66fec67aabd953e7b69993f60b00bca
Reviewed-on: https://go-review.googlesource.com/c/149339
Reviewed-by: Russ Cox <rsc@golang.org>
Since Reader.Peek potentially reads from the underlying io.Reader,
discarding previous buffers, UnreadRune and UnreadByte cannot
necessarily work. Change Peek to invalidate the unread buffers in all
cases (as allowed according to the documentation) and thus prevent
hiding bugs in the caller.
(This change was previoiusly merged and then reverted due concern about
being too close to a release)
Fixes#18556
Change-Id: I9027d75aa834d4b27703f37711ba25de04d89f3c
GitHub-Last-Rev: 917ef1e511
GitHub-Pull-Request: golang/go#28768
Reviewed-on: https://go-review.googlesource.com/c/149297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Followup to CL 129779 but also some other minor tweaks.
Change-Id: Id71455d8a14f5e33f82c942c9e892da56c49d17c
Reviewed-on: https://go-review.googlesource.com/c/149257
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The form of runtime.Version is not guaranteed to be helpful.
Do not suggest it. (The suggestion was added in CL 136215.)
Change-Id: I3227d2e66b6ce860b7e62d7ba531c18fb173823c
Reviewed-on: https://go-review.googlesource.com/c/149258
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 145577 added the part about io.ReadFull to read len(p)
but it should be next to the existing sentence about not
reading len(p) bytes.
Change-Id: Idfa037c59a3085d44d5da6129188473db0e96d23
Reviewed-on: https://go-review.googlesource.com/c/148903
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Adjusted spec to explicitly define the string length as the
number of bytes of the string; the prose now matches the prose
for arrays. Made analogous change for slices.
Fixes#28736.
Change-Id: I47cab321c87de0a4c482f5466b819b2cc8993fd1
Reviewed-on: https://go-review.googlesource.com/c/149077
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
To avoid any cancelation of the parent context from affecting
lookupGroup operations, Resolver.LookupIPAddr previously used
an entirely new context created from context.Background().
However, this meant that all the values in the parent context
with which LookupIPAddr was invoked were dropped.
This change provides a custom context implementation
that only preserves values of the parent context by composing
context.Background() and the parent context. It only falls back
to the parent context to perform value lookups if the parent
context has not yet expired.
This context is never canceled, and has no deadlines.
Fixes#28600
Change-Id: If2f570caa26c65bad638b7102c35c79d5e429fea
Reviewed-on: https://go-review.googlesource.com/c/148698
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Config does not own the memory pointed to by the Certificate slice.
Instead, opportunistically use Certificate.Leaf and let the application
set it if it desires the performance gain.
This is a partial rollback of CL 107627. See the linked issue for the
full explanation.
Fixes#28744
Change-Id: I33ce9e6712e3f87939d9d0932a06d24e48ba4567
Reviewed-on: https://go-review.googlesource.com/c/149098
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This adds the includes for errno.h to the windows stubs
for runtime/cgo so that "errno" is properly declared.
Due to "errno" not being properly declared, the compiler is
forced to assume it's an external which leaves it up to the
linker. This is an issue in some implementations as errno
might be a macro which results in an unresolved symbol error
during linking.
runtime/cgo/gcc_libinit_windows.c: added include
runtime/cgo/gcc_windows_386.c: added include
runtime/cgo/gcc_windows_amd64.c: added include
Change-Id: I77167d02f7409462979135efc55cf50bbc6bd363
GitHub-Last-Rev: 90da06ee3c
GitHub-Pull-Request: golang/go#28747
Reviewed-on: https://go-review.googlesource.com/c/149118
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
SSA lowering can create PFUNC ONAME nodes when compiling method calls.
Since we generally initialize the node's Sym to a func when we set its
class to PFUNC, we did this here, too. Unfortunately, since SSA
compilation is concurrent, this can cause a race if two function
compilations try to initialize the same symbol.
Luckily, we don't need to do this at all, since we're actually just
wrapping an ONAME node around an existing Sym that's already marked as
a function symbol.
Fixes the linux-amd64-racecompile builder, which was broken by CL
147158.
Updates #27539.
Change-Id: I8ddfce6e66a08ce53998c5bfa6f5a423c1ffc1eb
Reviewed-on: https://go-review.googlesource.com/c/149158
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
