The Go spec requires
If a deferred function value evaluates to nil, execution
panics when the function is invoked, not when the "defer"
statement is executed.
On Wasm and AIX, currently we actually emit a nil check at the
point of defer statement, which will make it panic too early.
This CL fixes this.
Also, on Wasm, now the nil function will be passed through
deferreturn to jmpdefer, which does an explicit nil check and
calls sigpanic if it is nil. This sigpanic, being called from
assembly, is ABI0. So change the assembler backend to also
handle sigpanic in ABI0.
Fixes#34926.
Updates #8047.
Change-Id: I28489a571cee36d2aef041f917b8cfdc31d557d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/201297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Do not modify the underlying Rat denominator when calling
one of the accessors Float32, Float64; verify that we don't
modify the Rat denominator when calling Inv, Sign, IsInt, Num.
Fixes#34919.
Reopens#33792.
Change-Id: Ife6d1252373f493a597398ee51e7b5695b708df5
Reviewed-on: https://go-review.googlesource.com/c/go/+/201205
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This new facility will be used by future CLs in this series.
Change the only blocking call to netpoll to do the right thing when
netpoll returns an empty list.
Updates #6239
Updates #27707
Change-Id: I58b3c2903eda61a3698b1a4729ed0e81382bb1ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/171821
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Per Jeremy's comment in CL 199643. This makes the code read
better.
Change-Id: If270aecd712a27fb52e3faf5a4339200327d9ffe
Reviewed-on: https://go-review.googlesource.com/c/go/+/201023
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
A contentless data symbol may be a declaration of a cgo-imported
variable, e.g.
//go:cgo_import_dynamic xxx
var xxx uintptr
In this case, we want to mark the symbol imported, instead of
defined with zero value.
We used to load cgo directives before loading the object file, so
we'll mark the symbol SDYNIMPORT first. But in newobj mode,
currently we load cgo directives later. Letting SDYNIMPORT
overwrite contentless data symbol makes it work in both ordering.
Change-Id: I878f52086d6cdb5a347669bf8f848a49bce87b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/201020
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
When a dupok symbol is resolved to another package, we still need
to record its presence in the current package, as the trampoline
pass expects packages are laid out in dependency order. At the
point after deadcode where we populate symbol contents for
reachable symbols (add relocations and read symbol data), make a
note of the dupok text symbols for each package. Later in
addToTextp we will visit packages in dependency order, process
the dup text symbol list for each package and select a final lib
for each dup text symbol.
Change-Id: Ib885e0a7e2343229d853aa629e3e337111df6011
Reviewed-on: https://go-review.googlesource.com/c/go/+/200797
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Add InlTree to the FuncInfo aux symbol in new object files.
In the linker, change InlinedCall.Func from a Symbol to a string,
as we only use its Name. (There was a use of Func.File, but that
use is not correct anyway.) So we don't need to create a Symbol
if not necessary.
Change-Id: I38ce568ae0934cd9cb6d0b30599f1c8d75444fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/200098
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
If two defined symbols have the same name, one contentless and
one with content, the one with content "wins". This is mainly for
go:linkname on data symbols. Support this logic in newobj mode.
Introduce an "overwrite" mechanism, letting one symbol overwrite
another. This machanism could later be used for the linker
overwriting symbol contents (e.g. -X flag).
Change-Id: I32ee7d4b82df275f11b38c3abefc99b878ff12d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/200097
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Use the auxiliary symbol mechanism to connect the text symbol and
its associated DWARF symbols. This way, the linker can track the
DWARF symbols from the text symbol, without looking up special
names.
Currently, in the linker this is only used in the deadcode pass
to track which DWARF symbols are used and need to load. Later
passes still use name lookup for now.
Change-Id: I2fe49f3b1f0ecc1472ae8aa93907cff740022d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/199801
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
With the new object files, now we can run the deadcode pass on
indices instead of Symbol structs, so we can delay creating
Symbols after the deadcode pass. Then we only need to create
reachable symbols.
Not create Symbols in LoadNew and LoadRefs, and recombine
LoadReloc into LoadFull.
Split loadcgo into two parts: the first finds root symbols, the
second create Symbols and sets attributes. The first runs before
the deadcode pass, while the second runs after.
TODO: currently there are still symbols that are not marked
reachable but still used. This includes DWARF symbols, file
symbols, and type symbols that are referenced by DWARF symbols.
We still need to create them (conservatively).
Change-Id: I695779c9312be9d49ab1683957ac3e72e1f65a1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/199643
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In the tzdata database CEST is not recognized as a timezone name.
It is used as the abbreviated name for daylight saving time in
Central Europe. Avoid using CEST in documentation as it suggests
that programs can parse dates that use CEST, which will typically
fail on Unix systems.
Updates #34913
Change-Id: I4b22f7d06607eb5b066812a48af58edd95498286
Reviewed-on: https://go-review.googlesource.com/c/go/+/201197
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This changes fixes an oversight in wakeScavenger which would cause ready
to be called off of the system stack. This change makes it so that
wakeScavenger calls goready, which switches to the system stack before
calling ready.
Fixes#34773.
Change-Id: Icb13f180b4d8fdd47c921eac1b896e3dd49e43b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/200999
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The old code does this. Do the same.
Change-Id: Ibf32ac347d6425e19ad0bc664c6b43ab5eba9c5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/201022
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When a subsequent load/store of a ptr makes the nil check of that pointer
unnecessary, if their lines differ, change the line of the load/store
to that of the nilcheck, and attempt to rehome the load/store position
instead.
This fix makes profiling less accurate in order to make panics more
informative.
Fixes#33724
Change-Id: Ib9afaac12fe0d0320aea1bf493617facc34034b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/200197
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 196781 added map[int64]uint32 to the set of things printed with %v.
Fixes#34907
Change-Id: If4a13e86cfb4b691988f5fb70449ae23760f5789
Reviewed-on: https://go-review.googlesource.com/c/go/+/201079
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was possible to get 'go env' to break itself:
$ go env -w GO111MODULE=bad
$ go env
go: unknown environment setting GO111MODULE=bad
We already check if the variable name is known. In some cases like
GO111MODULE, we also know what the variable's valid values are. Enforce
it when writing the variable, not just when fetching it.
Fixes#34880.
Change-Id: I10d682087c69f3445f314fd4473644f694e255f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/200867
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In CL 196030 we decided to combine the imported package list
(Autolib) and referenced package list (PkgIdx, or Pkglist).
However, in some cases the Autolib list may contain file name,
instead of package path, e.g.
https://go.googlesource.com/go/+/refs/heads/dev.link/src/cmd/compile/internal/gc/main.go#1181
And the linker needs that to locate the file. This mostly happens
with direct invocation of the compiler and linker (i.e., not
through "go build").
Instead of letting the linker make guess of the file name based
on the package path, make Autolib a separate list.
Change-Id: If195a69462d04db515346ee67cdec925f5a69e2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/200157
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Before this CL, inequality was recorded in a bit matrix using
SSA IDs. This allowed to record inequality for SSA values that
we didn't know any relation in the partial order of. Unfortunately,
this also means that inequality is harder to use within the poset
itself as there is not fast way to map from internal poset indices
and SSA values.
Since we will need to check for inequality in following CLs within
code that lost track of SSA values, switch to use a bit matrix
of poset indices instead. This requires always allocate a poset
node (as a new root) for values that are first seen in a SetNonEqual
call, but it doesn't sound like a big problem. The other solution
(creating and maintaining a reverse map from poset indices to SSA
values) seem more complicated and memory hungry.
Change-Id: Ic917485abbe70aef7ad6fa98408e5430328b6cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/196782
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, constants in posets, in addition to being stored in
a DAG, are also stored as SSA values in a slice. This allows to
quickly go through all stored constants, but it's not easy to search
for a specific constant.
Following CLs will benefit from being able to quickly find
a constants by value in the poset, so change the constants
structure to a map. Since we're at it, don't store it as
*ssa.Value: poset always uses dense uint32 indices when
referring a node, so just switch to it.
Using a map also forces us to have a single node per
constant value: this is a good thing in the first place,
so this CL also make sure we never create two nodes for
the same constant value.
Change-Id: I099814578af35f935ebf14bc4767d607021f5f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/196781
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The comment in both functions referred to the wrong header and I made
the checks easier to read.
Change-Id: Ifb46729cee631a3305f557863818e3487b8eed71
Reviewed-on: https://go-review.googlesource.com/c/go/+/71753
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add an internal mode to simplify debugging of posets
by checking the integrity after every mutation. Turn
it on within SSA checked builds.
Change-Id: Idaa8277f58e5bce3753702e212cea4d698de30ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/196780
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Fixes the docs to correctly match the implementation
and also adds a test locking-in the behavior to prevent
any accidental future regressions on the docs.
Fixes#33545
Change-Id: I6fdac6048cce8ac99beaa2db0dfc81d0dccc10f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200798
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The IsClosureVar, IsOutputParamHeapAddr, Assigned, Addrtaken,
InlFormal, and InlLocal flags are only interesting for ONAME nodes, so
it's better to set these flags on Name.flags instead of Node.flags.
Two caveats though:
1. Previously, we would set Assigned and Addrtaken on the entire
expression tree involved in an assignment or addressing operation.
However, the rest of the compiler only actually cares about knowing
whether the underlying ONAME (if any) was assigned/addressed.
2. This actually requires bumping Name.flags from bitset8 to bitset16,
whereas it doesn't allow shrinking Node.flags any. However, Name has
some trailing padding bytes, so expanding Name.flags doesn't cost any
memory.
Passes toolstash-check.
Change-Id: I7775d713566a38d5b9723360b1659b79391744c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/200898
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For Go 1.13 we introduced Header.Clone and it returns
nil if a nil Header is cloned. Unfortunately, though,
this exported Header.Clone nil behavior differed from
the old Go 1.12 and earlier internal header clone
behavior which always returned non-nil Headers.
This CL fixes the places where that distinction mattered.
Fixes#34878
Change-Id: Id19dea2272948c8dd10883b18ea7f7b8b33ea8eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/200977
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On AIX, a TOC symbol always has a relocation to its target symbol.
Instead of using name lookup to locate the target symbol, we can
just use the relocation.
Using name lookup, besides being less efficient, needs to provide
the right symbol version. In this particular case, we are looking
for a data symbol so it is almost always version 0. But in case
that it is a text symbol, we may get an ABIALIAS symbol, which
does not have its Sect set.
Change-Id: I1ecfd284b04a86bbbc450059ee89d99d40493e51
Reviewed-on: https://go-review.googlesource.com/c/go/+/201019
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On AIX, TOC symbols may be created and added to ctxt.Data
concurrently. To ensure reproducible builds, sort ctxt.Data.
This implements the same logic as WriteObjFile does for old
object files.
Change-Id: I2e6e2d7755352848981544a4fb68b828a188c2ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/201021
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Add to the testcase originally created for issue 34577 so
as to also trigger the error condition for issue 34852 (the
two bugs are closely related).
Updates #34577.
Updates #34852.
Change-Id: I2347369652ce500184347606b2bb3e76d802b204
Reviewed-on: https://go-review.googlesource.com/c/go/+/201017
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When reflect.Type.Method is called, all exported methods from a
reachable type need to be conservatively live. When such a
function is called, the compiler sets an attribute to the
function, and the linker needs to check that attribute. Implement
this in the index-based deadcode pass.
Unify symbol flags and FuncInfo flags to make things simpler. In
particular, the deadcode pass can check the reflectMethod
attribute without reading in and decoding FuncInfo.
Change-Id: Ibb21e172f2996e899c6efa5551a29d0eca62df67
Reviewed-on: https://go-review.googlesource.com/c/go/+/200099
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
For GOROOT packages, we were adding -unsafeptr=false to prevent unsafe.Pointer
checks. But the flag also got passed to invocations of go vet with a custom
vet tool. To prevent this from happening, we add this flag only when no
tools are passed.
Fixes#34053
Change-Id: I8bcd637fd8ec423d597fcdab2a0ceedd20786019
Reviewed-on: https://go-review.googlesource.com/c/go/+/200957
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This essentially replicates the logic of live method tracking and
type symbol decoding, rewritten to operate on indices instead of
Symbols.
TODO: the special handling of reflect.Type.Method has not been
implemented.
TODO: the symbol name is used too much. It ought to be a better
way to do it.
Change-Id: I860ee7a506c00833902e4870d15aea698a705dd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/199078
Reviewed-by: Than McIntosh <thanm@google.com>
These are unused since the darwin port switched to libc calls in
CL 148457.
Change-Id: I309bb5b0a52c9069484e7a649d4a652efcb8e160
Reviewed-on: https://go-review.googlesource.com/c/go/+/200866
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This flag is supposed to indicate whether the expression is
"addressable"; but in practice, we infer this from other
attributes about the expression (e.g., n.Op and n.Class()).
Passes toolstash-check.
Change-Id: I19352ca07ab5646e232d98e8a7c1c9aec822ddd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/200897
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This pseudo-Class was previously used by the importer code to optimize
processing duplicate inline bodies, since we didn't actually care
about the declarations in those contexts.
This functionality is no longer needed with indexed exports, since we
now only process function bodies as needed (and never more than once).
Passes toolstash-check.
Change-Id: I7eab0cb16925ab777079c2a20731dbcfd63cf195
Reviewed-on: https://go-review.googlesource.com/c/go/+/200899
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make it a bit more relaxed on the expected fairness, as fastrand()
isn't a truly perfect random number generator.
Fixes#34808
Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b
Reviewed-on: https://go-review.googlesource.com/c/go/+/200857
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Some nameservers alter the case of records as they return, e.g
.google.COM or .Google.com.
However according to RFC4343, DNS name should be treated in case insensitive fashion.
This CL will fix case sensitive testcases.
Fixes#34781
Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200277
Reviewed-by: Andrei Tudor Călin <mail@acln.ro>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When assessing whether A <= B, the poset's OrderedOrEqual has a passing
condition which permits A <= B, but is not sufficient to infer that A <= B.
This CL removes that incorrect passing condition.
Having identified that A and B are in the poset, the method will report that
A <= B if any of these three conditions are true:
(1) A and B are the same node in the poset.
- This means we know that A == B.
(2) There is a directed path, strict or not, from A -> B
- This means we know that, at least, A <= B, but A < B is possible.
(3) There is a directed path from B -> A, AND that path has no strict edges.
- This means we know that B <= A, but do not know that B < A.
In condition (3), we do not have enough information to say that A <= B, rather
we only know that B == A (which satisfies A <= B) is possible. The way I
understand it, a strict edge shows a known, strictly-ordered relation (<) but
the lack of a strict edge does not show the lack of a strictly-ordered relation.
The difference is highlighted by the example in #34802, where a bounds check is
incorrectly removed by prove, such that negative indexes into a slice
succeed:
n := make([]int, 1)
for i := -1; i <= 0; i++ {
fmt.Printf("i is %d\n", i)
n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!!
}
When prove is checking the negative/failed branch from the bounds check at n[i],
in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn
the OR condition, we check whether we know that i is non-negative so we can
learn something, namely that i >= len(n). Prove uses the poset to check whether
we know that i is non-negative. At this point the poset holds the following
relations as a directed graph:
-1 <= i <= 0
-1 < 0
In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3)
above is true because there is a non-strict path from i -> 0, and that path
does NOT have any strict edges. Because this condition is true, the poset
reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0,
prove learns from the failed bounds check that i >= len(n) in the signed domain.
When the slice, n, was created, prove learned that len(n) == 1. Because i is
also the induction variable for the loop, upon entering the loop, prove previously
learned that i is in [-1,0]. So when prove attempts to learn from the failed
bounds check, it finds the new fact, i > len(n), unsatisfiable given that it
previously learned that i <= 0 and len(n) = 1.
Fixes#34802
Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/200759
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Keith Randall <khr@golang.org>
