This patch has a couple of minor fixes to new-style counter insertion
(noticed these problems while working on the fix for issue 56370).
First, make sure that the function registration sequence (writing of
nctrs, pkgid, funcid to counter var prolog) comes prior to the first
counter update (they were reversed up to this point, due to an
artifact of the way cmd/internal/edit operates).
Second, fix up "per function" counter insertion mode (an experimental
feature disabled by default that adds just a single counter to each
function as opposed to one per basic block), which was failing to
insert the single counter in the right place.
Change-Id: Icfb613ca385647f35c0e52da2da8edeb2a506ab7
Reviewed-on: https://go-review.googlesource.com/c/go/+/444835
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
This patch fixes a problem in which we can get a data race on a
coverage counter function registration sequence. The scenario is that
package P contains a function F that is built with coverage, then F is
inlined into some other package that isn't being instrumented. Within
F's exported function body counter updates were being done with
atomics, but the initial registration sequence was not, which had the
potential to trigger a race. Fix: if race mode is enabled and we're
using atomics for counter increments, also use atomics in the
registration sequence.
Fixes#56370.
Change-Id: If274b61714b90275ff95fc6529239e9264b0ab0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/444617
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
If a user is running a go list command that wouldn't trigger a build
(for example if -export was passed), don't print the cached stdout
outputs for previous builds of the artifacts.
Fixes#56375
Change-Id: I1d3e6c01d0eb3dada941bb2783ce2ac69aa3d5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/444836
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
It was noted in the go1.9 release notes that functions in math/bits
may be implemented by compiler intrinsics, but this never made it to
the documentation.
This change adapts the wording of the release notes and puts it in the
documentation for math/bits.
Change-Id: Ibeea88eaf7df10952cbe670885e910ac30b49d55
Reviewed-on: https://go-review.googlesource.com/c/go/+/444035
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
windows-amd-2012 builder seems to have some problems handling
exception thrown in external C code which is affecting
TestVectoredHandlerExceptionInNonGoThread.
The issue is known and discussed in #49681.
This Cl skips the offending test on windows-amd-2012.
Change-Id: I7ca4353c9e531f0d75ac6a8dbd809acfa1f15bf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/444616
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This minimizes addi usage inside vector heavy loops. This
results in a small performance uptick on P9 ppc64le/linux.
Likewise, cleanup some minor whitespace issues around comments.
The implementation from crypto/sha256 is also shared with notsha256.
It is copied, but preserves notsha256's go:build directives. They are
otherwise identical now. Previously, bootstrap restrictions required
workarounds to support XXLOR on older toolchains. This is not needed
anymore as the minimum bootstrap (1.17) compiler will support XXLOR.
name old speed new speed delta
Hash8Bytes/New 28.8MB/s ± 0% 30.5MB/s ± 0% +5.98%
Hash8Bytes/Sum224 29.5MB/s ± 0% 31.3MB/s ± 0% +6.17%
Hash8Bytes/Sum256 29.5MB/s ± 0% 31.2MB/s ± 0% +5.80%
Hash1K/New 287MB/s ± 0% 312MB/s ± 0% +8.60%
Hash1K/Sum224 289MB/s ± 0% 312MB/s ± 0% +7.99%
Hash1K/Sum256 289MB/s ± 0% 312MB/s ± 0% +7.98%
Hash8K/New 313MB/s ± 0% 338MB/s ± 0% +8.12%
Hash8K/Sum224 313MB/s ± 0% 338MB/s ± 0% +8.20%
Hash8K/Sum256 313MB/s ± 0% 338MB/s ± 0% +8.12%
Change-Id: Ib386d6306673b4e6553ee745ec2e1b53a9722df1
Reviewed-on: https://go-review.googlesource.com/c/go/+/441815
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
The slice decode helpers weren't aware of partially allocated slices.
Also add large slice support for []byte.
Change-Id: I5044587e917508887c7721f8059d364189831693
Reviewed-on: https://go-review.googlesource.com/c/go/+/443777
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When a function type is copied (e.g. for substituting type
parameters), we make copies of its parameter ir.Name nodes, so
they are not shared with the old function type. But currently a
blank (_) identifier is not copied but shared. The parameter
node's frame offset is assigned (in ABI analysis) and then used in
the concurrent backend. Shared node can cause a data race. Make a
new blank parameter node to avoid sharing. (Unified IR does already
not have this problem. This fixes non-unified-IR mode.)
This seems to fix#55357.
Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/443158
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Error messages currently print floats with %.6g, which means that if
you tried to convert something close to, but not quite, an integer, to
an integer, the error you get looks like "cannot convert 1 to type
int", when really you want "cannot convert 0.9999999 to type int".
Add more digits to floats when printing them, to make it clear that they
aren't quite integers. This helps for errors which are the result of not
being an integer. For other errors, it won't hurt much.
Fixes#56220
Change-Id: I7f5873af5993114a61460ef399d15316925a15a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/442935
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This test is failing on the windows-arm64-10 builder
https://build.golang.org/log/c161c86be1af83c349ee02c1b12eff5828818f50.
It is not failing on windows-arm64-11, so I guess it has something to
do with the compiler.
This CL simplifies the test so is easier to build.
Change-Id: I6e0e1cf237277628f8ebf892c70ab54cd0077680
Reviewed-on: https://go-review.googlesource.com/c/go/+/444438
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
We add strict checking to marshal and unmarshal methods,
rather than Parse to maintain compatibility in Parse behavior.
Also, the Time.Format method has no ability to report errors.
The Time.Marshal{Text,JSON} and Time.Unmarshal{Time,JSON} methods
are already documented as complying with RFC 3339, but have
edge cases on both marshal and unmarshal where it is incorrect.
The Marshal methods already have at least one check to comply
with RFC 3339, so it seems sensible to expand this to cover
all known violations of the specification.
This commit fixes all known edge cases for full compliance.
Two optimizations are folded into this change:
1. parseRFC3339 is made generic so that it can operate
directly on a []byte as well as string.
This avoids allocating or redundant copying
when converting from string to []byte.
2. When marshaling, we verify for correctness based
on the serialized output, rather than calling
attribute methods on the Time type. For example,
it is faster to check that the 5th byte is '-'
rather than check that Time.Year is within [0,9999],
since Year is a relatively expensive operation.
Performance:
name old time/op new time/op delta
MarshalJSON 109ns ± 2% 99ns ± 1% -9.43% (p=0.000 n=10+10)
UnmarshalText 158ns ± 4% 143ns ± 1% -9.17% (p=0.000 n=9+9)
Updates #54580
Updates #54568
Updates #54571
Change-Id: I1222e45a7625d1ffd0629be5738670a84188d301
Reviewed-on: https://go-review.googlesource.com/c/go/+/444277
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, the lowerBlock function is reused with lateLowerValue, meaning
that any block rewriting rules in the late lower pass are silently ignored.
Change the late lower pass to actually use the lateLowerBlock function with
the lateLowerValue function.
Change-Id: Iaac1c2955bb27078378cac50cde3716e79a7d9f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/444335
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use rdtime to retrieve the timecounter, same as the FreeBSD libc.
Updates #53466
Change-Id: I48816e9100036f1ef483e4d3afcf10db0d3b85f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/443036
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Dmitri Goutnik <dgoutnik@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Yuval Pavel Zholkover <paulzhol@gmail.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
The package moved away from the deprecated ioutil API some time ago.
Change-Id: Iecb1baa9285af1f721a04eb40f8dafdd72474c4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/438515
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Replace even in places where before we have a specific error message
or different control-flow (except in TestTypeString or TestObjectString)
because failing to type-check in virtually all cases represents an error
in the test itself.
Change-Id: I9f1e6d25bddd92c168353409b281b5a3f29a747c
Reviewed-on: https://go-review.googlesource.com/c/go/+/443915
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Instead of having various inconsistent helper functions, rely on
4 helper functions with consistent naming and parameters:
- parse and mustParse
- typecheck and mustTypecheck
Panic rather than call t.Fatal in the mustX functions to simplify
their use.
Use the new functions in tests consistently.
Change-Id: Ib19dc5cc470b51512c23c09df32c379dc3eb8f4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/443757
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
All but local tests are now shared and reside in internal/types;
and there are no .go1 files anymore.
Change-Id: I3f8374e85639348de3cb8b568a7a05df5f9c2a38
Reviewed-on: https://go-review.googlesource.com/c/go/+/444276
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Now that we have an easy mechanism to set the Go version with a comment
line directly in test files, we don't need this flag anymore.
Change-Id: Ic1f1a6fdf2c6c692512bff49650916ec43645aee
Reviewed-on: https://go-review.googlesource.com/c/go/+/444275
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
If there is no current G while handling an exception it means
the exception was originated in a non-Go thread.
The best we can do is ignore the exception and let it flow
through other vectored and structured error handlers.
I've removed badsignal2 from sigtramp because we can't really know
if the signal is bad or not, it might be handled later in the chain.
Fixes#50877
Updates #56082
Change-Id: Ica159eb843629986d1fb5482f0b59a9c1ed91698
Reviewed-on: https://go-review.googlesource.com/c/go/+/442896
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
These tests previously had a “skipSpecialPlatforms” function, added in
CL 8611 to skip tests on (apparently) NaCL and iOS. The iOS builders
no longer match the condition (GOOS=ios is its own thing now), and the
NaCL port no longer exists.
The name of the function also isn't very evocative, since it doesn't
say what is “special” about the platforms to cause them to be
skipped.m
Since the check is intending to run the tests only on platforms where
gc export data is available, and to a first approximation
“gc export data is available” on exactly the platforms that can run
“go build” to produce that export data, we can use the testenv function
instead of a one-off.
Updates #38485.
Change-Id: I8f38b9604300d165147f8942e945ab762419fad7
Reviewed-on: https://go-review.googlesource.com/c/go/+/444155
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
js/wasm doesn't support os.Exec, so it can't run 'go list' to locate
export data for packages in the standard library.
This fixes js/wasm test failures introduced in CL 442303.
For #47257.
Change-Id: I39289f376691493aa6fb447b3329f6508ab48d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/444015
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Several OSes don't ever reach exitThread, On AIX, Plan9, Solaris, and
Windows, we throw if this function is accidentally reached. Do the same
on Darwin and OpenBSD for consistency.
Change-Id: Icd189b11179755a28b3ec48b267349c57facbf24
Reviewed-on: https://go-review.googlesource.com/c/go/+/443717
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.
Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.
Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.
Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.
Fixes#56243.
Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The mode is always 0.
Change-Id: I6566383c7724b26f070729041bce203a5afa0989
Reviewed-on: https://go-review.googlesource.com/c/go/+/443776
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To use an importer that knows where to find stdlib .a files based on
their new locations once the checked-in .a files are removed.
Change-Id: I981812306b3512380d58cb0f599a9a61b27ba0d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/442695
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
go/build and cmd/go will stop returing Targets for stdlib .a files, and
stop producing the .a files is pkg/GOOS_GOARCH. update tests to
anticipate that and to pass in importcfgs instead of expecting the
compiler can find .a files in their old locations.
Adds code to determine locations of .a files to internal/goroot. Also
adds internal/goroot to dist's bootstrap directories and changes
internal/goroot to build with a bootstrap version of Go.
Change-Id: Ie81e51105bddb3f0e374cbf47e81c23edfb67fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/442303
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
When computing package initialization order, special case the counter
variables inserted by "cmd/cover" for coverage instrumentation, since
their presence can perturb the order in which variables are
initialized in ways that are user-visible and incorrect with respect
to the original (uninstrumented) program.
Fixes#56293.
Change-Id: Ieec9239ded4f8e2503ff9bbe0fe171afb771b335
Reviewed-on: https://go-review.googlesource.com/c/go/+/443715
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Replace all uses of Ctz64/32/8 with TrailingZeros64/32/8, because they
are the same and maybe duplicated. Also renamed CtzXX functions in 386
assembly code.
Change-Id: I19290204858083750f4be589bb0923393950ae6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/438935
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
CL 428157 and CL 428759 switched debuglog to using unsafe.String and
unsafe.Slice, which broke the build with -tags=debuglog because this is
a no write barrier context, but runtime.unsafeString and unsafeSlice can
panic, which includes write barriers.
We could add a panicCheck1 path to these functions to reallow write
barriers, but it is a big mess to pass around the caller PC,
particularly since the compiler generates calls. It is much simpler to
just avoid unsafe.String and Slice.
Also add a basic test to build the runtime with -tags=debuglog to help
avoid future regressions.
For #54854.
Change-Id: I702418b986fbf189664e9aa4f40bc7de4d9e7781
Reviewed-on: https://go-review.googlesource.com/c/go/+/443380
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This sets up for delaying the decision of which seed to use,
but this CL still keeps the original global Seed(1) semantics.
Preparation for #54880.
Change-Id: Ibfa9d50ec9023aa755a83852e55168fa7d24b115
Reviewed-on: https://go-review.googlesource.com/c/go/+/443057
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The immediate reason is that we want to use godebug from math/rand,
and math/rand importing godebug importing os causes an import cycle
in package testing.
More generally, the new approach to backward compatibility outlined
in discussion #55090 will require using this package from other similarly
sensitive places, perhaps even package os itself. Best to remove all
dependencies.
Preparation for #54880.
Change-Id: Ia01657a2d90e707a8121a336c9db3b7247c0198f
Reviewed-on: https://go-review.googlesource.com/c/go/+/439418
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
UnsafePointer.Store, UnsafePointer.CompareAndSwap were missing,
although .StoreNoWB and .CompareAndSwapNoWB existed.
Same for Pointer[T}.
Do the linkname tricks necessary to add those methods.
Change-Id: I925ee27673288accb15ebe93898f9eb01ab46a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/443379
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I77c61211a488c66f1d445c0bf01e35aaf4f83565
GitHub-Last-Rev: c411a56a3b
GitHub-Pull-Request: golang/go#56279
Reviewed-on: https://go-review.googlesource.com/c/go/+/443316
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously we used Go 1.17, but we realized thanks to tickling
a pre-Go1.17.3 bug that if we are going to change the bootstrap
toolchain that we should default to the latest available point release
at the time we make the switch, not the initial major release, so as
to avoid bugs that were fixed in the point releases.
This CL updates the default search locations and the release notes.
Users who run make.bash and depend on finding $HOME/sdk/go1.17
may need to run
go install golang.org/dl/go1.17.13@latest
go1.17.13 download
to provide a Go 1.17.13 toolchain to their builds.
Change-Id: I3a2511f088cf852470a7216a5a41ae775fb561b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/439419
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The only purpose of using the SHA256 in the file name is
collision avoidance. Using just the first 64 bits (16 hex digits)
will be more than enough, unless people start storing billions
of test cases in their corpora.
The shorter names are nicer for just about everything:
command lines, repository listings, and so on.
Change-Id: I67c760023bed85ba3ffd4f8058f86ef778322ba7
Reviewed-on: https://go-review.googlesource.com/c/go/+/443335
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Add more skips if short mode testing, since some of these tests
still seem to be timing out on smaller and more underpowered
builders.
Updates #56197.
Change-Id: I469d9fd3a6be5602243234562fa3fe6263968b56
Reviewed-on: https://go-review.googlesource.com/c/go/+/443376
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
The src.NoXPos in fake receivers was leaking, through a series of
mishaps, all the way to logopt. If done just so, this can lead to
a compiler crash. This makes logopt crash-proof and eliminates the
root cause as well.
I'm reluctant to write a test for this because it's kinda slow
and involved; my working test is "compile something that mentions
the flag package with -json=0,$TMPDIR flag, then be sure that
$TMPDIR/flag/__unnamed__.json was not created".
Change-Id: I384b717c0e7522953d22d61f7e06319e11192d7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/443156
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, the entry-point to this test is a Bash script that smoke
tests the FORTRAN compiler and then runs a FORTRAN-containing Go test.
This CL rearranges things so a pure Go Go test smoke tests the FORTRAN
compiler and then runs a non-test FORTRAN-containing Go binary.
While we're here, we fix a discrepancy when the host is GOARCH=amd64,
but the target is GOARCH=386. Previously, we would pick the wrong
libgfortran path because we didn't account for the cross-compilation,
causing the link to fail. Except for some reason this was ignored and
the test nevertheless "passed". In the new test we're a little more
strict, so this build failure will cause the test to fail, so we add a
little logic to account for cross-compilation with the host toolchain.
For #37486.
Change-Id: Ie6f70066885d6fbb4e1b5a2b1e13b85dee5b359b
Reviewed-on: https://go-review.googlesource.com/c/go/+/443069
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
This test was originally Linux-only, but there doesn't seem to be
anything Linux-specific in it.
Change-Id: I0f8519eff5dbed97f5e21e1c8e5ab0d747d51df3
Reviewed-on: https://go-review.googlesource.com/c/go/+/443073
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, TestCgoSigfwd will pass incorrectly if the SIGSEGV that
originates in Go mistakenly goes to the C SIGSEGV handler. Fix this by
adding a signal-atomic variable that tracks what the expected behavior
is.
Change-Id: Id2a9fa3b209299dccf90bb60720b89ad96838a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/443072
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
