For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I1488726e5b43cd21c5f83900476afd2fb63d70c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479622
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Fixes#54768
Change-Id: I588ae33c13e0bbd9d324c11771667b22a864047d
Reviewed-on: https://go-review.googlesource.com/c/go/+/483175
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Use the type of the store for the byteswap, not the type of the
store's value argument.
Normally when we're storing a 16-bit value, the value being stored is
also typed as 16 bits. But sometimes it is typed as something smaller,
usually because it is the result of an upcast from a smaller value,
and that upcast needs no instructions.
If the type of the store's arg is thinner than the type being stored,
and the byteswap'd value uses that thinner type, and the byteswap'd
value needs to be spilled & restored, that spill/restore happens using
the thinner type, which causes us to lose some of the top bits of the
value.
Fixes#59367
Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/481395
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
HashDebugPos function/method included a parameter that was always
the same, and a variable in the same package as the hashdebug code.
So remove it.
(I wrote that code, there was no reason for it to be that way).
Also corrects a stale comment in the loopvar code.
Change-Id: Id3da69cfe6dadeb31d5de62fb76d15103a5d6152
Reviewed-on: https://go-review.googlesource.com/c/go/+/482816
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The ELF ABI just requires that the address and the offset of a
segment are congruent modulo the alignment, but does not require
the start address to be aligned. While usually the segment's
start address is aligned, apparently the zig linker generates
binary with unaligned address.
At the run time, the memory mapping that contains the segment
starts at an aligned address (rounding down). Use the aligned
address for the load address, which matches the mapping.
Apparently this is what the pprof library expects.
Fixes#59466.
Change-Id: Ife78909b20b7bc975ac4c76f2c5f5db325ddec9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/483035
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The loong64 PCALIGN directive works with PCs relative to beginning of
functions. So if the function alignment is less than that requested by
PCALIGN, the following code may in fact not be aligned as such, leading
to unexpected performance.
The current function alignment on loong64 is 8 bytes, which seems to
stem from mips64 or riscv64. In order to make performance more
predictable on loong64, it is raised to 16 bytes to ensure that at
least `PCALIGN $16` works.
As alignment of loops written in Go is yet to be tackled, and the
codegen is not otherwise touched, benchmark numbers for this change are
not going to be meaningful, and not included.
Change-Id: I2120ef3746ce067e274920c82091810073bfa3be
Reviewed-on: https://go-review.googlesource.com/c/go/+/481936
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Allow writing `PCALIGN $imm` where imm is a power-of-2 between 8 and
2048 (inclusive), for ensuring that the following instruction is
placed at an imm-byte boundary relative to the beginning of the
function. If the PC is not sufficiently aligned, NOOPs will be
inserted to make it so, otherwise the directive will do nothing.
This could be useful for both asm performance hand-tuning, and future
scenarios where a certain bigger alignment might be required.
Change-Id: Iad6244669a3d5adea88eceb0dc7be1af4f0d4fc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479815
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Like https://go.dev/cl/481376 did for encoding/gob,
but now for encoding/xml, which had very similar code.
One minor difference is that encoding/xml now needs a SetLen before the
call to Index, as otherwise we index just past the length.
Still, calling Grow and SetLen is easier to understand,
and avoids needing to make a new zero value.
goos: linux
goarch: amd64
pkg: encoding/xml
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
Unmarshal-8 6.904µ ± 1% 6.980µ ± 1% +1.10% (p=0.009 n=6)
│ old │ new │
│ B/op │ B/op vs base │
Unmarshal-8 7.656Ki ± 0% 7.586Ki ± 0% -0.92% (p=0.002 n=6)
│ old │ new │
│ allocs/op │ allocs/op vs base │
Unmarshal-8 188.0 ± 0% 185.0 ± 0% -1.60% (p=0.002 n=6)
Change-Id: Id83feb467a9c59c80c7936aa892780aae7e8b809
Reviewed-on: https://go-review.googlesource.com/c/go/+/483135
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Expose "http: server gave HTTP response to HTTPS client" error as `ErrSchemeMismatch`, so that it can be compared with `errors.Is` .
Fixes#44855
Change-Id: If96e0d000fdef641fea407310faf9e1c4f7ad0f0
GitHub-Last-Rev: 22879fc883
GitHub-Pull-Request: golang/go#50939
Reviewed-on: https://go-review.googlesource.com/c/go/+/382117
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 440035 added rewrite rules to simplify "costly" LEA
instructions, but the types in the rewrites were wrong and
the code would go bad if the wrong-typed register was spilled.
CL 482536 attempted to fix this by correcting the type in the
rewrite, but that "fix" broke something on windows-amd64-race.
Instead / for-now, remove the offending rewrite rules.
Updates #21735.
Fixes#59432.
Change-Id: I0497c42db414f2055e1378e0a53e2bceee9cd5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/482820
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
After performing a round trip on a connection, the connection is
usually returned to the idle connection pool. If the write of the
request did not complete successfully, the connection is not
returned.
It is possible for the response to be read before the write
goroutine has finished signalling that its write has completed.
To allow for this, the check to see if the write completed successfully
waits for 50ms for the write goroutine to report the result of the
write.
See comments in persistConn.wroteRequest for more details.
On a slow builder, it is possible for the write goroutine to take
longer than 50ms to report the status of its write, leading to test
flakiness when successive requests unexpectedly use different connections.
Set the timeout for waiting for the writer to an effectively
infinite duration in tests.
Fixes#51147Fixes#56275Fixes#56419Fixes#56577Fixes#57375Fixes#57417Fixes#57476Fixes#57604Fixes#57605
Change-Id: I5e92ffd66b676f3f976d8832c0910f27456a6991
Reviewed-on: https://go-review.googlesource.com/c/go/+/483116
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
If the Write goroutine is delayed for long enough after its first
Write, the handler may have closed both the readc and donec channels
by the time it selects over them, and the donec case may be randomly
chosen. Handle that case by explicitly checking readc as well.
This fixes a race accidentally introduced in CL 482935 and observed in
https://build.golang.org/log/fa684750994d1fda409722f144b90c65b4c52cf9.
For #59447.
Change-Id: I5c87a599910cf8c1d037e5bbce68bf35afd55d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/483036
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis since fixed in CL 482355.]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I1f4fc96c71609c8feb59fecdb92b69ba7e3b5b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/482356
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When a closure is inlined, it may contain other hidden closures, which
the inliner will duplicate, rendering the original nested closures as
unreachable. Because they are unreachable, they don't get processed in
escape analysis, meaning that go/defer statements don't get rewritten,
which can then in turn trigger errors in walk. This patch looks for
nested hidden closures and marks them as dead, so that they can be
skipped later on in the compilation flow. NB: if during escape
analysis we rediscover a hidden closure (due to an explicit reference)
that was previously marked dead, revive it at that point.
Fixes#59404.
Change-Id: I76db1e9cf1ee38bd1147aeae823f916dbbbf081b
Reviewed-on: https://go-review.googlesource.com/c/go/+/482355
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously we did not permit them as Go programs generated enormous
core dumps on macOS. However, according to an investigation in #59446,
they are OK now.
For #59446
Change-Id: I1d7a3f500a6bc525aa6de8dfa8a1d8dbb15feadc
Reviewed-on: https://go-review.googlesource.com/c/go/+/483015
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
PCrelative trampolines have no dependence on the TOC pointer or build
mode, thus they are preferable to use when supported.
This is a step towards eliminating the need to use and maintain the
TOC pointer in R2 when PCrel is supported.
Change-Id: I1b1a7e16831cfd6732b31f7fad8df2a7c88c8f84
Reviewed-on: https://go-review.googlesource.com/c/go/+/461599
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
The IMAGE_FILE_DEBUG_STRIPPED characteristic is used to inform that
the debugging information have been removed from the PE files and moved
into a DBG file, but the Go linker doesn't generate DBG files.
Having this characteristic can confuse debugging tools, so better
don't set it.
While here, remove also IMAGE_FILE_LINE_NUMS_STRIPPED, which is
deprecated and should be zero [1].
Fixes#59391
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#characteristics
Change-Id: Ia6b1dc3353bfa292a17c4bef17c9bac8dc95189a
Reviewed-on: https://go-review.googlesource.com/c/go/+/481615
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently, the prove pass can get knowledge from some specific logic
operators only before the CFG is explored, which means that the bounds
information of the branch will be ignored.
This CL updates the facts table by the logic operators in every
branch. Combined with the branch information, this will be helpful for
BCE in some circumstances.
Fixes#57243
Change-Id: I0bd164f1b47804ccfc37879abe9788740b016fd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419555
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The test file has a C declaration which doesn't match the actual
definition. Remove it and include "_cgo_export.h" to have the
right declaration.
Change-Id: Iddf6d8883ee0e439147c7027029dd3e352ef090d
Reviewed-on: https://go-review.googlesource.com/c/go/+/482975
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
A test flake in #59447 seems to indicate that this test got stuck
waiting for the test handler to close the readc channel.
If the handler returns early due to an unexpected error, it might
fail to close this channel. Add a second channel to act as a
signal that the handler has given up and the test should stop.
This won't fix whatever happened in the flake, but might help
us debug it if it happens again.
For #59447
Change-Id: I05d84c6176aa938887d93126a6f3bb4dc941c90d
Reviewed-on: https://go-review.googlesource.com/c/go/+/482935
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
This script uses Wazero, the open source, zero dependencies
pure Go Wasm and WASI runtime. This is the runtime that allows
the greatest number of standard library tests to pass.
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I789465ae4daf2b380f3c05a9365b8d449c6af56c
Reviewed-on: https://go-review.googlesource.com/c/go/+/479620
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This setting appears to be needed to avoid “Filename too long” errors
when downloading modules from repos with long branch names,
particularly if the path to the module cache is already fairly long
(as may be the case in CI systems and in tests of cmd/go itself).
Change-Id: I3aa89ea872b29eb0460c8a8afc94f182a68982fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/482819
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The compiler disallows line and column numbers > (1<<30)
(cmd/compiler/internal/syntax.PosMax).
Set the go/scanner limit to the same rather than off by one.
For #59180
Change-Id: Ibf9e0e6826d6f6230b0d492543b7e906298a0524
Reviewed-on: https://go-review.googlesource.com/c/go/+/482595
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
ServeFile and FileServer will respond to methods such as DELETE by
serving the file contents. This is surprising, but we don't want to
change it without some consideration.
Add tests covering the current behavior.
For #59470
Change-Id: Ib6a2594c5b2b7f380149fc1628f7204b308161e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/482876
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix two long tests that fail in the builders we're trying out:
- TestQueryImport was failing with:
open /nonexist-gopath/pkg/sumdb/sum.golang.org/latest: no such file or directory
which eventually turns out to be because it couldn't create
/nonexist-gopath because it wasn't running as root. The test already
uses a temporary GOPATH, but missed overriding a configuration
variable set at init time.
- test_flags fails if the working directory has /x/ in it, which it now
happens to.
Change-Id: Ideef0f318157b42987539e3a20f9fba6a3d3bdd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/480255
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Implements OS interactions and memory management.
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I876e7b033090c2fe2d76d2535bb63d52efa36185
Reviewed-on: https://go-review.googlesource.com/c/go/+/479618
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
This reverts https://go.dev/cl/413554
Reason for revert: Backwards-incompatible change in behavior.
For #53501
For #59375
Change-Id: Ic3f63b378f9c819599b32e5e6e410f6163849317
Reviewed-on: https://go-review.googlesource.com/c/go/+/482635
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The goal here is to enable a search that will locate all the instances
of a failure, not just the first one. This helps with searches for
loopvar-change breakage, FP differences from fused-multiply-add, and
allows certain semantics queries that can be implemented as compiler
changes (for example, where does integer overflow routinely occur?)
Change-Id: Ic28f1695d47e421c2089d1f3f7c4b40c56db970f
Reviewed-on: https://go-review.googlesource.com/c/go/+/481195
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The wrong type causes the wrong width spill, which corrupts
the value. I tried to write a test for this and did not
succeed, but was able (using gossahash and ssa.html) to
isolate to exact change and spill.
Fixes#59432.
Change-Id: I85ad82c9f8fed7674c69d6a2b0a62e111f690454
Reviewed-on: https://go-review.googlesource.com/c/go/+/482536
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently pages may linger in an idle P's page cache, hiding the memory
from the scavenger precisely when it's useful to return memory to the OS
and reduce the application's footprint.
Change-Id: I49fbcd806b6c66991d1ca87949f76a9f06708e70
Reviewed-on: https://go-review.googlesource.com/c/go/+/453622
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently the memory limit is left uninitialized before gcinit, and
allocations may happen. The result is that the span allocation path
might try to scavenge memory unnecessarily. Prevent this by setting the
memory limit up early to its default value.
Change-Id: I886d9a8fa645861e4f88e0d54af793418426f520
Reviewed-on: https://go-review.googlesource.com/c/go/+/450736
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL updates the Go compiler so it generate SEH unwind info [1] as a
function auxiliary symbol when building for windows/amd64.
A follow up CL will teach the Go linker how to assemble these codes
into the PE .xdata section.
Updates #57302
[1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-unwind_info
Change-Id: I40ae0437bfee326c1a67c2b5e1496f0bf3ecea17
Reviewed-on: https://go-review.googlesource.com/c/go/+/461749
Reviewed-by: Davis Goodin <dagood@microsoft.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This allows for a large number of casts to be removed at call sites.
While here, use consistent register naming.
Change-Id: I78a2a928b78c9f09f91fb6ed6ad440aa4e63923d
Reviewed-on: https://go-review.googlesource.com/c/go/+/471517
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This allows for a large number of casts to be removed at call sites.
While here, use consistent register naming.
Change-Id: I68cee985f6500ed9523f7fb3efbc11bb849681dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/471516
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This allows for a large number of casts to be removed at call sites.
Change-Id: I44a162040cc5b4de02e106d3a6de10f8e0870cb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/471515
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add wasip1 asm and symbols to cmd/internal/obj, cmd/link and
runtime.
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: Ie088d9b65ea13e231694af6341465f95be33093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/479617
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
When taking over the goroutine stack in the panic or preemption signal
handlers on arm64, the frame pointer should be saved on the stack (like
the link register) so that frame-pointer unwinding from a panic stack
works properly. Otherwise, tests like TestStackWrapperStackPanic will
fail with the frame pointer check in adjustframe (enabled with
debugCheckBP) when checking the sigpanic frame.
Updates #39524, #58432
Change-Id: I8b89e6fc4877af29b1b81e55e591e6398159855c
Reviewed-on: https://go-review.googlesource.com/c/go/+/481635
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Unified IR already records the correct type for them.
Fixes#59378
Change-Id: I275c45b48f67bde55c8e2079d60b5868d0acde7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/481555
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Tests in package context cannot depend directly on package testing due to an import cycle.
We resolved this by having test functions in package context_test (x_test.go) forward to
test functions in package context (context_test.go). This is fragile, since it's easy
to add a test to context_test.go and forget to add the forwarding function, and tests
written in this way cannot easily use testing package features like t.Run for subtests.
It turns out that only four test functions actually use unexported members of package
context. This CL moves all except those four to x_test.go and makes them regular tests.
It also updates TestCause to use t.Run and t.Parallel to parallelize its test cases.
It also adds documentation indicating when tests should be added to each file.
Change-Id: Ic60bae32a7a44e07831b5388c9af219d53ba9af3
Reviewed-on: https://go-review.googlesource.com/c/go/+/480375
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This change documents the new GODEBUG settings introduced for
html/template and mime/multipart, released with Go 1.19.8 and Go 1.20.3
as part of a security fix.
Updates #59153.
Updates #59234.
Change-Id: I25f4d8245da3301dccccfb44da8ff1a5985392a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/482238
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
zip.NewReader was recently improved to return ErrInsecurePath when
insecure entries are encountered.
This change adopts the same logic for the OpenReader interface as well.
Fixes#58641
Change-Id: I0d8be94d073cc14cf93a914dc250f85b19cec4ab
GitHub-Last-Rev: 68391dc515
GitHub-Pull-Request: golang/go#58658
Reviewed-on: https://go-review.googlesource.com/c/go/+/470735
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
The posix_fallocate syscall returns the result in r1 rather than in
errno:
> If successful, posix_fallocate() returns zero. It returns an error on failure, without
> setting errno.
Source: https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2&n=1
Adjust the PosixFallocate wrappers on freebsd to account for that.
Also, CL 479715 used the same syscall wrapper for 386 and arm. However,
on arm the syscall argument order is different. The wrapper was
generated using mksyscall.go from the golang.org/x/sys/unix package,
adjusting the r1 check correspondingly.
Fixes#59352
Change-Id: I9a4e8e4546237010bc5e730c4988a2a476264cf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/481621
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Yuval Pavel Zholkover <paulzhol@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
