| Age | Commit message (Collapse) | Author |
|
In the environment where GOMAXPROCS set explicitly, for example to 3 in
shell profile, the runtime tests will fail with the following error,
----
ok regexp/syntax 0.428s
--- FAIL: TestCgroupGOMAXPROCS (0.81s)
crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe
crash_test.go:208: built testprog in 796.664277ms
--- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s)
cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok
cgroup_linux_test.go:63: output got "3\n" want "4\n"
--- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s)
cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok
cgroup_linux_test.go:85: output got "3\n" want "4\n"
--- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s)
cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok
cgroup_linux_test.go:105: output got "3\n" want "4\n"
--- FAIL: TestCgroupGOMAXPROCSRound (0.01s)
--- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s)
cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok
cgroup_linux_test.go:159: output got "3\n" want "2\n"
--- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s)
cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok
cgroup_linux_test.go:159: output got "3\n" want "2\n"
--- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s)
cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok
cgroup_linux_test.go:159: output got "3\n" want "2\n"
--- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s)
cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok
cgroup_linux_test.go:232: output got "3\n" want "2\n"
FAIL
FAIL runtime 23.088s
----
This changes exclude the GOMAXPROCS when building program for testing so it
does not affect the tests.
|
|
When test run with "-count=Y" and Y is greater that 1, print a line
to indicated the current round of test as "### X/Y".
|
|
This reduce the struct encodeState size from 56 to 16 bytes (-42),
struct structFields size from 40 to 24 bytes (-16), and struct field size
from 136 to 128 bytes (-8).
Benchmark memory profiling before and after,
File: json.test
Type: alloc_space
Time: Jan 25, 2024 at 4:51am (WIB)
Showing nodes accounting for -4.01GB, 4.66% of 85.95GB total
Dropped 64 nodes (cum <= 0.43GB)
flat flat% sum% cum cum%
-4.25GB 4.94% 4.94% -4.01GB 4.67% encoding/json.Marshal
0.19GB 0.22% 4.73% 0.24GB 0.28% encoding/json.mapEncoder.encode
0.05GB 0.057% 4.67% 0.05GB 0.057% reflect.copyVal
0.04GB 0.049% 4.62% 0.04GB 0.049% bytes.growSlice
-0.04GB 0.045% 4.66% -0.04GB 0.045% encoding/json.RawMessage.MarshalJSON
0 0% 4.66% 0.04GB 0.046% bytes.(*Buffer).WriteString
0 0% 4.66% 0.04GB 0.049% bytes.(*Buffer).grow
0 0% 4.66% -0.04GB 0.045% encoding/json.(*Encoder).Encode
0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).marshal
0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).reflectValue
|
|
This reduce the UnmarshalTypeError size from 64 to 56 bytes (-8 bytes),
and decodeState from 128 to 96 (-32 bytes).
|
|
This reduce the Scanner allocation size from 112 to 72 bytes.
|
|
This reduce the Reader allocation size from 72 to 40 bytes and
Writer allocation size from 64 to 40 bytes.
|
|
Given the following example of message body,
A line that precisely have length 75 with . + LF will cause DATA truncation.\n
\n
Footer.\n
The quotedprintable Writer will encode the message into,
A line ... truncation=\r\n
.\r\n
\r\n
Footer.\r\n
If we pass the Writer output into SMTP DATA command, the server read
the "\r\n.\r\n" as the end of DATA which cause the message truncated
on the receiver.
This changes fix this issue by encode the period at the end with "=2E"
based on recommendation in RFC 2049 Section 3, point (8) [1].
[1] https://www.rfc-editor.org/rfc/rfc2049.html#section-3
Fixes #61235
Change-Id: I350387b183ac6b25886f4084a060dcfcb48232a9
|
|
Instead of re-slicing the string for checking the value, use single
index variable.
Benchmark result,
name old time/op new time/op delta
NumberIsValid-8 19.0ns ± 0% 14.5ns ± 1% -23.70% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
NumberIsValid-8 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
NumberIsValid-8 0.00 0.00 ~ (all equal)
Change-Id: I4698c5db134998f83ff47fb3add6a04ba6ec3aa0
|
|
|
|
Fixes #77404
Change-Id: I0402becb94855baf942d6ba3815cc2a3c1526d6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/740921
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
The temporary was not being deleted. Not creating it at all is better.
Change-Id: Id9c5498a2f7d2f58770a09a2a76f4ab30943dd3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/740780
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
CL 734980 swapped use of Type.Underlying() in Checker.hasVarSize for
traversal of Named.fromRHS. It forgot to call Named.unpack() before
inspecting Named.fromRHS, allowing access of unexpanded instantiated
types.
These unexpanded instantiated types are then mistakenly marked as having
fixed size, which fails assertions downstream. This change adds the
missing Named.unpack() call and swaps direct access of Named.fromRHS for
Named.rhs(), which verifies such access in debug mode.
Fixes #77382
Change-Id: I324bbbbf790f8b09e95902ebe67f775483f88417
Reviewed-on: https://go-review.googlesource.com/c/go/+/740620
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Add a convenience function which combines time.Sleep and synctest.Wait.
Fixes #77169
Change-Id: I2ff105105e95cfd8e5b4f72ccacf7afa59efb6bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/740066
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
mapaccess2*
mapaccess1* and mapaccess2* functions share the same implementation and differ only in whether the boolean "found" is returned.
This change replaces mapaccess1* calls with mapaccess2*.
We can do this transparently, since the call site can safely discard the second (boolean) result.
Ideally, mapacces1* functions could be removed entirely, but this change keeps them as thin wrappers for compatibility.
Fixes #73196
Change-Id: I07c3423d22ed1095ac3666d00e134c2747b2f9c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/736020
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Due to the lack of MarshalWrite in the v1 API,
it is unfortunately common to see:
json.NewEncoder(out).Encode(in)
where a single-use Encoder is constructed and thrown away.
This performed acceptably in v1 since every call to Encode
used a globally pooled encoder resource.
Prior to this change, the v1-in-v2 implementation relied
on a bytes.Buffer cached only for the lifetime of the Encoder
object itself. Thus, a single-use Encoder does not benefit.
Modify the wrapper implementation to use the internal
pooled encoder from v2 and use the intermediate buffer
to write directly to the output io.Writer.
We assume that the user-provided io.Writer never leaks the buffer,
but this assumption was already held in the v1 implementation.
We are not increasing the surface area of data corruption risk.
Performance of v1 to v1-in-v2 (before the pool fix):
name old time/op new time/op delta
NewEncoderEncode-32 30.2ms ± 4% 28.3ms ± 9% -6.19% (p=0.002 n=9+10)
name old alloc/op new alloc/op delta
NewEncoderEncode-32 7.64MB ± 0% 28.37MB ± 0% +271.23% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
NewEncoderEncode-32 200k ± 0% 100k ± 0% -49.99% (p=0.000 n=9+10)
Interestingly, v1-in-2 is slightly faster,
but the amount of allocated memory is massive.
Performance of v1 to v1-in-v2 (after the pool fix):
name old time/op new time/op delta
NewEncoderEncode-32 30.2ms ± 4% 24.0ms ± 7% -20.36% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
NewEncoderEncode-32 7.64MB ± 0% 4.09MB ± 3% -46.52% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
NewEncoderEncode-32 200k ± 0% 100k ± 0% -50.00% (p=0.000 n=9+9)
Now, the v1-in-v2 implementation is better than v1 on all metrics.
Fixes #75026
Change-Id: I50c975b1d5b8da806e46bc627966b0a39c1817eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/740660
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The code was using defer in TestMain, but was also calling os.Exit,
which meant that the deferred functions did not run.
TestMain does not require calling os.Exit, so stop doing it.
Change-Id: I25ca64c36acf65dae3dc3f46e5fa513b9460a8e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/740781
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Updates #77113
Updates #77217
Updates CVE-2025-68121
Change-Id: Ia47904a9ed001275aad0243a6a0ce57e6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/740240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
|
|
This is a step towards deferring adding the handle to IOCP until the
first IO operation.
The goal of this CL is to avoid the fd.isBlocking check in fd.pin,
which was happening outside execIO, and making buffer pinning less
error-prone.
This also fixes an issue where buffer used in Pwrite and WriteTo
were unpinned too early when the write buffer was larger than the
maximum chunk size.
For #76391
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: Ia181dcb57a559ae466a4341c36a307ad6678aac0
Reviewed-on: https://go-review.googlesource.com/c/go/+/740561
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This is a step towards deferring adding the handle to IOCP until the
first IO operation.
The main goal of this CL is to remove the fd.pollable() check in
cancelIO.
For #76391
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: I76263ce12980297d88a5f6c514e4074dfee428cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/740540
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
If a Go process starts up, finds /etc/resolv.conf empty, then the DHCP
client writes /etc/resolv.conf, the Go program would find itself
broken for up to 5 seconds.
We noticed this during integration tests in ephemeral VMs using
gokrazy that boot into our application.
Change-Id: Ia64c2b5c698a4ee3efc15d8a8f1850c47e531b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/739620
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Currently, we have a rather inconsistent behavior in terms of whether a
connection can be re-used or not when an HTTP body is not read to
completion:
- In HTTP/2, not reading bodies to completion is not an issue, since a
new HTTP/2 stream can be created on the same TCP connection.
- In HTTP/1 server, we discard up to 256 KiB of unconsumed request body,
to potentially allow re-use.
- In HTTP/1 client, we do not do anything, and fail to re-use a TCP
connection if there are any unconsumed response body at all.
This has led to some confusion. For example, some users have mistakenly
discarded response body for HTTP/2 when doing so is not needed. Manually
discarding response body can also be disadvantageous if the body is
excessively large or is a never-ending stream.
To solve this issue, this CL makes it so that closing a response body
will cause any remaining content to be drained, up to a limit of 256 KiB
or 50 milliseconds, whichever one is reached first. This allows better
connection re-use for HTTP/1, and most users can now avoid having to
manually drain their response body.
For #77370
Change-Id: I71e1227fc9cf5f901362c8e234320817f6b0be24
Reviewed-on: https://go-review.googlesource.com/c/go/+/737720
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
Load constant keys from a static memory table rather than loading immediates into registers on loong64.
Benchmark for Loongson-3A5000:
goos: linux
goarch: loong64
pkg: crypto/sha1
cpu: Loongson-3A5000-HV @ 2500.00MHz
│ old │ new │
│ sec/op │ sec/op vs base │
Hash8Bytes/New-4 235.9n ± 0% 229.1n ± 0% -2.88% (p=0.000 n=8)
Hash8Bytes/Sum-4 1.892µ ± 0% 1.882µ ± 0% -0.50% (p=0.000 n=8)
Hash320Bytes/New-4 1022.0n ± 0% 963.8n ± 0% -5.70% (p=0.000 n=8)
Hash320Bytes/Sum-4 1037.0n ± 0% 981.1n ± 0% -5.39% (p=0.000 n=8)
Hash1K/New-4 2.760µ ± 0% 2.594µ ± 0% -6.01% (p=0.000 n=8)
Hash1K/Sum-4 2.775µ ± 0% 2.610µ ± 0% -5.95% (p=0.000 n=8)
Hash8K/New-4 20.46µ ± 0% 19.20µ ± 0% -6.17% (p=0.000 n=8)
Hash8K/Sum-4 20.49µ ± 0% 19.22µ ± 0% -6.17% (p=0.000 n=8)
geomean 2.498µ 2.377µ -4.87%
│ old │ new │
│ B/s │ B/s vs base │
Hash8Bytes/New-4 32.34Mi ± 0% 33.30Mi ± 0% +2.98% (p=0.000 n=8)
Hash8Bytes/Sum-4 4.034Mi ± 0% 4.053Mi ± 0% +0.47% (p=0.000 n=8)
Hash320Bytes/New-4 298.7Mi ± 0% 316.7Mi ± 0% +6.02% (p=0.000 n=8)
Hash320Bytes/Sum-4 294.3Mi ± 0% 311.0Mi ± 0% +5.69% (p=0.000 n=8)
Hash1K/New-4 353.8Mi ± 0% 376.5Mi ± 0% +6.41% (p=0.000 n=8)
Hash1K/Sum-4 351.9Mi ± 0% 374.1Mi ± 0% +6.31% (p=0.000 n=8)
Hash8K/New-4 381.8Mi ± 0% 406.9Mi ± 0% +6.57% (p=0.000 n=8)
Hash8K/Sum-4 381.4Mi ± 0% 406.4Mi ± 0% +6.58% (p=0.000 n=8)
geomean 146.1Mi 153.6Mi +5.11%
Change-Id: I7305caefa1434ab2bb4ce94a1c789d4ee5b7ccf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/732580
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
delete unused parameter userForced
Change-Id: I71c26ab5e3fadc532b6b1f266212c6f620769efd
GitHub-Last-Rev: 6a32c8ff6e63f8b149c0803e8b6636022bd9d066
GitHub-Pull-Request: golang/go#76732
Reviewed-on: https://go-review.googlesource.com/c/go/+/727680
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Tony Tang <jianfeng.tony@gmail.com>
|
|
This is part of a series of CLs that aim to reduce how often
interface arguments escape for the print functions in fmt,
such as val here:
func f(val int) {
fmt.Sprintf("%d", val)
}
Prior to this change, arguments immediately escape in doPrintf
because they are stored on the *pp in printArg:
parameter a leaks to <heap> for (*pp).doPrintf with derefs=1:
flow: <heap> ← *a:
from a[argNum] (dot of pointer) at .\print.go:1077:18
from (*pp).printArg(p, a[argNum], rune(c)) (call parameter) at .\print.go:1077:16
parameter arg leaks to <heap> for (*pp).printArg with derefs=0:
flow: <heap> ← arg:
from p.arg = arg (assign) at .\print.go:682:8
The *pp is heap allocated, and the heap cannot point to stack
variables, so the arguments currently cannot be on the stack.
This change instead threads through the input arguments as individual
type any and reflect.Value parameters, rather than storing on the *pp.
After this change, input arguments still escape, but now for
other reasons.
Updates #8618
Updates #62653
Change-Id: I81984daeceb761ce4ce269b150b888950ce2c5d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/524938
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
with gosave_systemstack_switch
gosave_systemstack_switch saves PC with fixed offset of 8 bytes from systemstack_switch to bypass prologue.
This commit makes this offset consistent with actual address of UNDEF instruction intended to be at that address.
Fixes #71440
Change-Id: Ibe6458c5bcb0bdaec228a2f13d6aec7ecc0e319e
Reviewed-on: https://go-review.googlesource.com/c/go/+/740360
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Go is only capable of producing internally linked, static binaries
on linux-ppc64. As such, binaries should run in either ELFv1 or
ELFv2 ppc64 userspaces today.
This opens the door to enabling cgo and external linking which
will require ELFv2 support and userspace, eventually.
Fixes #76244
Change-Id: I5ca15037cbe546f352e8693dcf14da51a308b8ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/734540
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
tautological/impossible nil conditions
Change-Id: I3cdc599ebc93f5c9be5645e7ef7ce167242d9c1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/739800
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
to autotmp variable scope
The motivating example I created for #73137 still seems
to heap allocate in go1.26rc2 when used in a b.Loop body.
│ go1.25 │ go1.26rc2 │
│ allocs/op │ allocs/op vs base │
NewX/b.Loop-basic-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹
I suspect it is because the temps are by default declared
outside the loop body, which escape analysis will determine is
an escaping value and result in a heap allocation. (I've seen
this problem before, including in my older CL 546023 that attempts
to help PGO with a similar issue.)
This is an attempt to address that by placing ODCLs within the
b.Loop body for the temps that are created so that they can be
marked keepalive.
There are two cases handled in the CL: function return values
and function arguments. The first case is what affects my example
from #73137, and is also illustrated via the NewX test case in
the new test/escape_bloop.go file.
Without this CL, the NewX call in the BenchmarkBloop test is inlined,
which is an improvement over Go 1.25, but the slice still escapes
because the temporary used for the return value is declared outside
the loop body.
With this CL, the slice does not escape.
The second case is illustrated via the new BenchmarkBLoopFunctionArg
test, which shows a function argument that escapes without this CL
but does not escape with this CL.
We can also make the two new b.Loop tests in testing/benchmark_test.go
individually pass or fail as expected based on individually
reverting the two changes in this CL.
While we are here, we add a note to typecheck.TempAt to help
make people aware of this behavior.
Updates #73137
Fixes #77339
Change-Id: I69abe978367a8d3a931430aec5d85c9c54b42c1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/738822
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
That used to happen naturally because the symbol had zero size.
After CL 724261 we need to force it.
Fixes #77372
Change-Id: Ia8eef989bc9cbad5459b60ff6535136e7e0c6cab
Reviewed-on: https://go-review.googlesource.com/c/go/+/740400
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Given:
s := /* slice */
k := /* proved valid index in s (0 <= k < len(s)) */
v := s[k:]
len(v) >= 1, so v[0] needs no bounds check. However, for
len(v) = len(s) - k, we only checked if len(s) >= k and so could only
prove len(v) >= 0, thus the bounds check wasn't removed.
As far as I can tell these checks were commented out for performance,
but after benchmarking prove I see no difference.
Fixes: #76429
Change-Id: I39ba2a18cbabc0559924d4d226dcb99dbe9a06ed
GitHub-Last-Rev: 53f3344d261986cd021c8d7b8435ab89b5438b8f
GitHub-Pull-Request: golang/go#76609
Reviewed-on: https://go-review.googlesource.com/c/go/+/725100
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
It doesn't seem to be necessary, and removing it seems cleaner
than adding an AIX case to the code in runtime.moduleTypelinks.
Fixes #77365
Change-Id: I59fa56abf42e18017bd112481ea09d0cca47d105
Reviewed-on: https://go-review.googlesource.com/c/go/+/740220
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Each time I go to definition of this I am deeply confused
at what I am looking, so let's clean this a bit with modern Go.
Change-Id: I8f44e78f0cdde9b970388f9b98a2720e6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/738341
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
This XCOFF symkind comparison broke when STYPE moved in CL 723580.
These comparisons are unmaintainable, but at least the new code
is no worse than the old code.
Change-Id: I1be9de6afdf1814aaadcd2105e6247a4b66b46fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/740200
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
|
|
The duff device has been dropped on loong64,
now we can remove related documentation.
Change-Id: I0bd721adc227522ae3c56dfe199ef735cfdf5d33
Reviewed-on: https://go-review.googlesource.com/c/go/+/740260
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Maybe fixes a dashboard build failure for linux/arm32 casued
by CL 724261.
This value comes from cmd/link/internal/arm/l.go (and in general,
maxAlign in cmd/link/internal/$ARCH/<something>.go).
Change-Id: I4d02cd41072da1b6ad6c7405044bd7788626b013
Reviewed-on: https://go-review.googlesource.com/c/go/+/740101
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Storing the type descriptor length lets us save a relocation.
It also avoids a problem for Darwin dynamic linking.
For #6853
Fixes #77350
Change-Id: If5c94330fe10d75690325f3d0b0658060ef3eb2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/739681
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Updates #54941
Change-Id: I62406c53b5b27742003098c77cfba0a96a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/738720
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Also drop the scannerhooks code, as it is now unused.
Updates #74958
Updates #76031
Change-Id: I5a0cb8a7fe954e40ce40b8406aed0d3f6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/738701
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Updates #74958
Change-Id: I43dcbff6ec828bddf157b2e6ec80df526a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/738700
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Fixes #74958
Change-Id: I50ef64ae9ae6a762a7aada3d29914bae6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/738681
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Using the FSEL instruction on loong64 to eliminate branches and reduce
pipeline interruptions.
On the Loongson CPU 3A6000, there is a 0.09% performance improvement, as follows:
goos: linux
goarch: loong64
pkg: math/big
cpu: Loongson-3A6000-HV @ 2500.00MHz
│ old.bench │ new.bench │
│ sec/op │ sec/op vs base │
Exp 7.748m ± 0% 7.740m ± 0% -0.10% (p=0.001 n=10)
Exp2 7.747m ± 0% 7.741m ± 0% -0.09% (p=0.002 n=10)
geomean 7.747m 7.740m -0.09%
Change-Id: If62f2e81bf345c83a1fa9350ace131240cfa3b9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/693458
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
|
|
Change-Id: I34678f4ef17fe1b8b7657a2c3d39685b4a5951f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/739981
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
The code previously filters out VAES-only instructions, this CL added
them back.
This CL added the VAES feature check following the Intel xed data:
XED_ISA_SET_VAES: vaes.7.0.ecx.9 # avx.1.0.ecx.28
This CL also found out that the old AVX512VAES feature check is not
checking the correct bits, it also fixes it:
XED_ISA_SET_AVX512_VAES_128: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_256: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_512: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16
It restricts to the most strict common set - includes avx512vl for even
512-bits although it doesn't requires it.
Change-Id: I4e2f72b312fd2411589fbc12f9ee5c63c09c2e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/738500
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Calling Read with a nil or empty slice previously caused a panic with
"index out of range" because the function unconditionally accessed the
first element of the slice (via &m[0]) to pass the pointer to the
runtime.
This change adds a check for len(m) == 0 to return early, preventing
the panic when no samples are provided.
Fixes #77231
Change-Id: I442635f5c61de432883c8d0efae9cc6aa1363cc9
GitHub-Last-Rev: 6f24f67b18c77a0b36b92017a3f4ef8aa3aa5229
GitHub-Pull-Request: golang/go#77233
Reviewed-on: https://go-review.googlesource.com/c/go/+/737380
Reviewed-by: Amol Yadav <amolyadav6125@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Commit-Queue: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
When resuming TLS sessions, on the server and client verify that the
chains stored in the session state (verifiedChains) are still acceptable
with regards to the Config by checking for the inclusion of the root in
either ClientCAs (server) or RootCAs (client). This prevents resuming
a session with a certificate chain that would be rejected during a full
handshake due to an untrusted root.
Updates #77113
Updates #77217
Updates CVE-2025-68121
Change-Id: I11fe00909ef1961c24ecf80bf5b97f7b1121d359
Reviewed-on: https://go-review.googlesource.com/c/go/+/737700
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
When resuming a session, check that the verifiedChains contain at least
one chain that is still valid at the time of resumption. If not, trigger
a new handshake.
Updates #77113
Updates #77217
Updates CVE-2025-68121
Change-Id: I14f585c43da17802513cbdd5b10c552d7a38b34e
Reviewed-on: https://go-review.googlesource.com/c/go/+/739321
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
This reverts CL 736709 (commit bba24719a4cad5cc8d771fc9cfff5a38019d554a).
Updates #77113
Updates CVE-2025-68121
Change-Id: I0261cb75e9adf9d0ac9890dc91ae8476b8988ba0
Reviewed-on: https://go-review.googlesource.com/c/go/+/739320
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
loong64 supports R+R addressing ({st,ld}x.{b,h,w,d} instructions)
and has implemented the relevant lowering rules (only width is 1).
Removes 1616 instructions from the go binary on loong64.
file before after Δ %
asm 575366 575314 -52 -0.0090%
cgo 489972 489884 -88 -0.0180%
compile 2920418 2920110 -308 -0.0105%
cover 540458 540290 -168 -0.0311%
fix 865840 865668 -172 -0.0199%
link 732858 732662 -196 -0.0267%
preprofile 246022 245978 -44 -0.0179%
vet 839268 839124 -144 -0.0172%
go 1666470 1666114 -356 -0.0214%
gofmt 326526 326438 -88 -0.0270%
total 9203198 9201582 -1616 -0.0176%
Change-Id: If3518547c785764877a6cf987781d43d8b572990
Reviewed-on: https://go-review.googlesource.com/c/go/+/738240
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Ref: #733621
Updates #75463
Change-Id: Idd8821d1713754097a2fe83a050c25d9ec5b17eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/735540
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
In the mips{,64} instruction sets and their extensions, there is no
NORI instruction.
Change-Id: If008442c792297d011b3d0c1e8501e62e32ab175
Reviewed-on: https://go-review.googlesource.com/c/go/+/735900
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|