Blanks can only appear on the LHS of an assignment. Instead of
handling them as an arbitrary expression, handle them as part of
assignee expression lists.
Change-Id: Iaeb0a5c471ffa1abd2bbbd9c95f7876533e5a607
Reviewed-on: https://go-review.googlesource.com/c/go/+/410100
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Previously, {writer,reader}.expr would allow for nil
expressions (i.e., no expression at all, not a "nil" identifier). But
only a few contexts allow this, and it simplifies some logic if we can
assume the expression is non-nil.
So this CL introduces optExpr as a wrapper method for handling nil
expressions specially.
Change-Id: I438bae7a3191126f7790ec0bf5b77320fe855514
Reviewed-on: https://go-review.googlesource.com/c/go/+/410099
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
As of this CL, release notes for all packages owned by @golang/runtime
on https://dev.golang.org/owners are either complete or have explicit
TODOs.
For #51400
Change-Id: I5b6affd43883991a3b8a065b4aa211efce7427f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/410118
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
This documents most of the changes in runtime packages, which the major
exception of GC changes, which will be documented in a future CL.
For #51400
Change-Id: Ibcf501e1b4f7caa3397db6b9136daec07aac5a65
Reviewed-on: https://go-review.googlesource.com/c/go/+/410117
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently the GC CPU limiter only tracks idle GC work time. However, in
very undersubscribed situations, it's possible that all this extra idle
time prevents the enabling of the limiter, since it all gets account for
as mutator time. Fix this by tracking all idle time via pidleget and
pidleput. To support this, pidleget and pidleput also accept and return
"now" parameters like the timer code.
While we're here, let's clean up some incorrect assumptions that some of
the scheduling code makes about "now."
Fixes#52890.
Change-Id: I4a97893d2e5ad1e8c821f8773c2a1d449267c951
Reviewed-on: https://go-review.googlesource.com/c/go/+/410122
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Either due to a new nowritebarrierrec annotation or a change in escape
analysis, printDebuglog can't be called from sighandler anymore.
Fix this by avoiding a string allocation that's the primary culprit.
Change-Id: Ic84873a453f45852b0443a46597ed3ab8c9443fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/410121
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the GC CPU limiter consumes CPU time from a few pools, but
because the events that flush to those pools may overlap, rather than be
strictly contained within, the update window for the GC CPU limiter, the
limiter's accounting is ultimately sloppy.
This sloppiness complicates accounting for idle time more completely,
and makes reasoning about the transient behavior of the GC CPU limiter
much more difficult.
To remedy this, this CL adds a field to the P struct that tracks the
start time of any in-flight event the limiter might care about, along
with information about the nature of that event. This timestamp is
managed atomically so that the GC CPU limiter can come in and perform a
read of the partial CPU time consumed by a given event. The limiter also
updates the timestamp so that only what's left over is flushed by the
event itself when it completes.
The end result of this change is that, since the GC CPU limiter is aware
of all past completed events, and all in-flight events, it can much more
accurately collect the CPU time of events since the last update. There's
still the possibility for skew, but any leftover time will be captured
in the following update, and the magnitude of this leftover time is
effectively bounded by the update period of the GC CPU limiter, which is
much easier to consider.
One caveat of managing this timestamp-type combo atomically is that they
need to be packed in 64 bits. So, this CL gives up the top 3 bits of the
timestamp and places the type information there. What this means is we
effectively have only a 61-bit resolution timestamp. This is fine when
the top 3 bits are the same between calls to nanotime, but becomes a
problem on boundaries when those 3 bits change. These cases may cause
hiccups in the GC CPU limiter by not accounting for some source of CPU
time correctly, but with 61 bits of resolution this should be extremely
rare. The rate of update is on the order of milliseconds, so at worst
the runtime will be off of any given measurement by only a few
CPU-milliseconds (and this is directly bounded by the rate of update).
We're probably more inaccurate from the fact that we don't measure real
CPU time but only approximate it.
For #52890.
Change-Id: I347f30ac9e2ba6061806c21dfe0193ef2ab3bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/410120
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After CL 381317 there exist values that may have an alignment greater
than the pointer size for that platform. Specifically, atomic.{Ui|I}nt64
may be aligned to 8 bytes on a 32-bit platform. If such a value, or
a container for the value, gets stack-allocated, it's possible that it
won't be aligned correctly, because the maximum alignment we enforce on
stacks is governed by the pointer size. Changing that would be a
significant undertaking, so just escape these values to the heap
instead, where we're sure they'll actually be aligned correctly.
Change is by rsc@, I'm just shepherding it through code review.
For #50860.
Change-Id: I51669561c0a13ecb84f821020e144c58cb528418
Reviewed-on: https://go-review.googlesource.com/c/go/+/410131
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL makes the changes to actually use the module index when loading
packages and instead of scanning their directories to see if they
contain go files or to extract imports.
Change-Id: I70106181cf64d6fd5a416644ba518b6b90030e0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/403778
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
The data read is used for three primary functions: ImportPackage,
IsDirWithGoFiles and ScanDir. Functions are also provided to get this
information from the intermediate package representation to cache
the information from reads for non-indexed packages.
Change-Id: I5eed629bb0d6ee5b88ab706d06b074475004c081
Reviewed-on: https://go-review.googlesource.com/c/go/+/403975
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
For #51400
Change-Id: If5fc131df254d47a989ff61c8e584cb8149cbd09
Reviewed-on: https://go-review.googlesource.com/c/go/+/410116
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Do not need to add single quotes '' when passing the parameter value of
the -ldflags option, otherwise the following error will be reported:
invalid value "'-linkmode=external'" for flag -ldflags: parameter may
not start with quote character.
Change-Id: I322fa7079ac24c8a68d9cb0872b0a20dbc4893d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/410074
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
A clean up for CL 408734, suggested by Joe Tsai.
Change-Id: Ida9db0b8d31785d5640938c286c9c6c82c27f457
Reviewed-on: https://go-review.googlesource.com/c/go/+/410154
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Fix a build failure when bootstrapping the Go compiler with go-bootstrap 1.4
while the environment contains GOARCH=riscv64.
Building Go toolchain1 using go-1.4-bootstrap-20171003.
src/cmd/compile/internal/ssa/rewriteRISCV64.go:4814
invalid operation: y << x (shift count type int64, must be unsigned integer)
This is because:
- buildtool.go:198: calls bootstrapRewriteFile(src)
- bootstrapRewriteFile: buildtool.go:283 calls:
- isUnneededSSARewriteFile: checks os.Getenv("GOARCH")
- isUnneededSSARewriteFile: returns "", false
- bootstrapRewriteFile: calls bootstrapFixImports
- boostrapFixImports: generates code go1.4 cannot compile
Instead of checking "GOARCH" in the environment, use the gohostarch variable.
Change-Id: Ie9c190498555c4068461fead6278a62e924062c6
GitHub-Last-Rev: 300d7a7fea
GitHub-Pull-Request: golang/go#52362
Reviewed-on: https://go-review.googlesource.com/c/go/+/400376
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
This permits us to read files that earlier Go releases could read.
It is also compatible with other zip programs.
Change-Id: I7e2999f1073c4db5ba3f51f92681e0b149d55b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/408734
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I71c9d9ef9d21a7ae9466d8c7b283fdfbba01f5a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/390734
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change functions to scan modules and packages into an intermediate
RawPackage struct and also functions to write them out to and index.
Change-Id: Ia1a3b58b992e9be52c5d1397e85c642f902011cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/398415
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
We have noticed a pattern of connection timeouts connecting to
github.com on the builders. Adding tracing may shed some light on the
underlying cause.
For #52545.
Change-Id: Ic73b494be9a3ea8ce3c7631ee8f62bd3d0d8e7bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/409575
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For instantiated generic functions, all implicit dot operations are
resolved. Thus unsafe.Offsetof may calculating the offset against the
wrong base selector.
To fix it, we must remove any implicit dot operations to find the first
non-implicit one, which is the right base selector for calculating the
offset.
Fixes#53137
Change-Id: I38504067ce0f274615b306edc8f7d7933bdb631a
Reviewed-on: https://go-review.googlesource.com/c/go/+/409355
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In the windows version of OutBuf.munmap, call syscall.FlushFileBuffers
after the call to syscall.FlushViewOfFile, on the theory that this
will help flush all associated meta-data for the file the linker is
writing.
Updates #44817.
Change-Id: Ibff7d05008a91eeed7634d2760153851e15e1c18
Reviewed-on: https://go-review.googlesource.com/c/go/+/406814
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Version 2022a was released on 2022-03-15 and we can start using it for
Go 1.19. Its release announcement was:
https://mm.icann.org/pipermail/tz-announce/2022-March/000070.html
For #22487.
Change-Id: Ie89b90927a251413e4f67c9e0ed3a67d4161529b
Reviewed-on: https://go-review.googlesource.com/c/go/+/409374
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This reverts commit CL 401754 (440c9312c8) which reverted CL 400654,
thus reapplying CL 400654, re-adding the func init() { netGo = true }
to cgo_stub.go CL 400654 had originally removed (mistakenly during
development?) that had broken the darwin nocgo builder.
Fixes#33097
Change-Id: I90f59746d2ceb6b5d2bd832c9fc90068f8ff7417
Reviewed-on: https://go-review.googlesource.com/c/go/+/409234
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This seems to be a common registry misconfiguration on Windows.
Fixes#32350
Change-Id: I68c617c42a6e72948e2acdf335ff8e7df569432d
Reviewed-on: https://go-review.googlesource.com/c/go/+/406894
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
As far as I can tell, this test suffers from #52433. For some reason,
this seems to become more of a problem on the windows/386 than anywhere
else. This CL is an attempt at a mitigation by slowing down the
allocation rate by inserting runtime.Gosched call in the inner loop. It
also cuts the iteration count which should help too (as less memory is
allocated in total), but the main motivation is to make sure the test
doesn't take too long to run.
Fixes#49564.
Change-Id: I8cc622b06a69cdfa66f680a30e1ccf334eea2164
Reviewed-on: https://go-review.googlesource.com/c/go/+/408825
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change forces mark and scavenge assists to be cancelled early if
the limiter is enabled. This avoids goroutines getting stuck in really
long assists if the limiter happens to be disabled when they first come
into the assist. This can get especially bad for mark assists, which, in
dire situations, can end up "owing" the GC a really significant debt.
For #52890.
Change-Id: I4bfaa76b8de3e167d49d2ffd8bc2127b87ea566a
Reviewed-on: https://go-review.googlesource.com/c/go/+/408816
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This fix is analogous to the one in CL 407888.
'go vet' catches the error, but it is not run on this file because the
file is (only) compiled when running testsanitizers/TestTSAN.
Fixes#53113.
Change-Id: I74f7b7390a9775ff00a06214c1019ba28846dd11
Reviewed-on: https://go-review.googlesource.com/c/go/+/409094
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
It's already mentioned under runtime/race, we don't need it
also mentioned under runtime.
Change-Id: I538322b32d75b9642f3ead03539fccb95988ef8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/408875
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
CL 392134 appears to have been marked for the release notes by accident.
Remove mention of this package.
Change-Id: I62ae30512512ef8e20e9040b71e613be5ee5ee26
Reviewed-on: https://go-review.googlesource.com/c/go/+/408819
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Auto-Submit: Alex Rakoczy <alex@golang.org>
For #51400.
Change-Id: I122b3a58e5fbaaa8ceb5b013e8e392f4bcbbd2e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/408495
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Cgo TSAN (not the Go race detector) intercepts signals and calls
the signal handler at a later time. When the signal handler is
called, the memory may have changed, but the signal context
remains old. As the signal context and the memory don't match, it
is unsafe to unwind the stack from the signal PC and SP. We have
to ignore the signal.
It is probably also not safe to do async preemption, which relies
on the signal PC, and inspects and even writes to the stack (for
call injection).
We also inspect the stack for fatal signals (e.g. SIGSEGV), but I
think they are not delayed. For other signals we don't inspect
the stack, so they are probably fine.
Fixes#27540.
Change-Id: I5c80a7512265b8ea4a91422954dbff32c6c3a0d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/408218
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
We choose 64 because the L1 Dcache of Loongson 3A5000 CPU is
4-way 256-line 64-byte-per-line.
Change-Id: Ifb9a9f993dd6f75b5adb4ff6e4d93e945b1b2a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/408854
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The linux/loong64 kernel ABI has changed a little since the inception
of the Go port; most notably fstat and fstatat are being removed [1],
leaving only statx as the stat mechanism. Fortunately the structs are
easy enough to translate, and we now exclusively use statx across the
board on loong64 for best compatibility with past and future kernels
(due to the architecture's young age, statx is always available).
In wiring up the statx calls, it turned out the linux/loong64 syscall
definitions were out-of-date, so the generation script received some
tweaking as well.
[1]: https://lore.kernel.org/all/20220518092619.1269111-1-chenhuacai@loongson.cn/
Change-Id: Ifebb9ab9fef783683e453fa331d623575e824a48
Reviewed-on: https://go-review.googlesource.com/c/go/+/407694
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
As of CL 334732 `go build` can accept `$CC` with spaces and quotes,
which lets us easily use `zig cc` as the C compiler, or easily pass
extra compiler parameters:
```
CC="zig cc" go build <...>
CC="clang-13 -v" go build <...>
CC="zig cc -Wl,--print-gc-sections" go build <...>
```
However, the same does not apply for building go itself:
```
$ CC="zig cc" ./make.bash
Building Go cmd/dist using /usr/local/go. (go1.18.2 linux/amd64)
go tool dist: cannot invoke C compiler "zig cc": exec: "zig cc": executable file not found in $PATH
Go needs a system C compiler for use with cgo.
To set a C compiler, set CC=the-compiler.
To disable cgo, set CGO_ENABLED=0.
```
With this change Go can be built directly with `zig cc` (the linker arg
will disappear with CL 405414):
```
$ CC="zig cc -Wl,--no-gc-sections" ./make.bash
Building Go cmd/dist using /usr/local/go. (go1.18.2 linux/amd64)
Building Go toolchain1 using /usr/local/go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.
---
Installed Go for linux/amd64 in /home/motiejus/code/go
Installed commands in /home/motiejus/code/go/bin
$ ../bin/go version
go version devel go1.19-811f1913a8 Thu May 19 09:44:49 2022 +0300 linux/amd64
```
Fixes#52990
Change-Id: I66b3525d47db488d3c583c1aee3af78060fd5a38
GitHub-Last-Rev: ecc70d7224
GitHub-Pull-Request: golang/go#52991
Reviewed-on: https://go-review.googlesource.com/c/go/+/407216
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 401434.
Reason for revert: We should't deprecate these without a replacement.
Fixes#53079
Change-Id: I5515b03e39787d4e528a98c733cdb643b86b17ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/408815
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Change-Id: Ica05b2b699d8f6383c713460a473ccf753bc78c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/408494
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes "GOARCH=loong64 go vet runtime/internal/syscall"
Change-Id: I5879eec3ff07b0c69a5a8ac8e854733261e98fbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/408695
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
zig cc passes `--gc-sections` to the underlying linker, which then
causes undefined symbol errors when compiling with cgo but without C
code. Add `-Wl,--no-gc-sections` to make it work with zig cc. Minimal
example:
**main.go**
package main
import _ "runtime/cgo"
func main() {}
Run (works after the patch, doesn't work before):
CC="zig cc" go build main.go
Among the existing code, `src/runtime/testdata/testprognet` fails to
build:
src/runtime/testdata/testprognet$ CC="zig cc" go build .
net(.text): relocation target __errno_location not defined
net(.text): relocation target getaddrinfo not defined
net(.text): relocation target freeaddrinfo not defined
net(.text): relocation target gai_strerror not defined
runtime/cgo(.text): relocation target stderr not defined
runtime/cgo(.text): relocation target fwrite not defined
runtime/cgo(.text): relocation target vfprintf not defined
runtime/cgo(.text): relocation target fputc not defined
runtime/cgo(.text): relocation target abort not defined
runtime/cgo(.text): relocation target pthread_create not defined
runtime/cgo(.text): relocation target nanosleep not defined
runtime/cgo(.text): relocation target pthread_detach not defined
runtime/cgo(.text): relocation target stderr not defined
runtime/cgo(.text): relocation target strerror not defined
runtime/cgo(.text): relocation target fprintf not defined
runtime/cgo(.text): relocation target abort not defined
runtime/cgo(.text): relocation target pthread_mutex_lock not defined
runtime/cgo(.text): relocation target pthread_cond_wait not defined
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined
runtime/cgo(.text): relocation target pthread_cond_broadcast not defined
runtime/cgo(.text): relocation target malloc not defined
With the patch both examples build as expected.
@ianlancetaylor suggested:
> It would be fine with me if somebody wants to send a cgo patch that
passes -Wl,--no-gc-sections, with a fallback if that option is not
supported.
... and this is what we are doing. Tested with zig
0.10.0-dev.2252+a4369918b
This is a continuation of CL 405414: the original one broke AIX and iOS
builds. To fix that, added `unknown option` to the list of strings
under lookup.
Fixes#52690
Change-Id: Id6743e1e759a02627b0fc6d2ac89bb69b706d04c
GitHub-Last-Rev: 86f227a14e
GitHub-Pull-Request: golang/go#53028
Reviewed-on: https://go-review.googlesource.com/c/go/+/407814
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
We were dropping the preceding whitespace.
Fixes#53059
Change-Id: Ide0d6a76c463a7481ec4883a8568f7f7b5e87e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/408394
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
