cmd/compile: remove unused arg from gorecover

We don't need this argument anymore to match up
a recover with its corresponding panic.

Change-Id: I5d3646cdd766259ee9d3d995a2f215f02e17abc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/685555
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>

runtime: iterate through inlinings when processing recover()

We care about the wrapper-ness of logical frames, not physical frames.

Fixes #73916
Fixes #73917
Fixex #73920

Change-Id: Ia17c8390e71e6c0e13e23dcbb7bc7273ef25da90
Reviewed-on: https://go-review.googlesource.com/c/go/+/685375
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

encoding/json: fix truncated Token error regression in goexperiment.jsonv2

The jsontext.Decoder.ReadToken method reports a non-EOF error,
if the token stream is truncated and does not form a valid JSON value.
In contrast, the v1 json.Decoder.Token method would report EOF
so long as the input was a prefix of some valid JSON value.
Modify json.Decoder.Token to preserve historical behavior.

This only modifies code that is compiled in under goexperiment.jsonv2.

Updates #69449
Fixes #74750

Change-Id: Ifd281c46f118f0e748076013fefc7659f77c56ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/689516
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

encoding/json/jsontext: preserve buffer capacity in Encoder.Reset

This does the equivalent of CL 681177 for the Encoder.
It preserves the internal buffer between resets.

Change-Id: I5e9353b6d7755e067d4f9a4d1ea3d8f056253027
Reviewed-on: https://go-review.googlesource.com/c/go/+/690375
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

reflect: avoid a bounds check in stack-constrained code

Since CL 682496 we need more stack space to handle bounds checks.
The code modified here normally has no bounds checks, but in -N
builds it still does and thus uses too much stack.

Use unsafe arithmetic to avoid the bounds check.

This will hopefully fix some of the arm64 linux builders.

Change-Id: I5b3096a14b4fb9553e635b7f340e60b8ffba8755
Reviewed-on: https://go-review.googlesource.com/c/go/+/690415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>

encoding/json: fix extra data regression under goexperiment.jsonv2

When operating under v1 semantics in the v2 implementation,
a extra data error should take precedence over any semantic error
that could theoretically occur within the value itself.

This change only affects code compiled under goexperiment.jsonv2.

Fixes #74614

Change-Id: I055a606b053fa66b0c766ae205487b8290109285
Reviewed-on: https://go-review.googlesource.com/c/go/+/689919
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

encoding/json: reduce error text regressions under goexperiment.jsonv2

There were minor and unnecessary error text changes
when v1 was implemented using v2.
Reduce divergences if possible.

Of the cases reported in #74713, there are no more differences for:

v1: json: cannot unmarshal number into Go value of type chan int
v2: json: cannot unmarshal number into Go value of type chan int

and

v1: json: cannot unmarshal number into Go value of type error
v2: json: cannot unmarshal number into Go value of type error

However, there is a difference between:

v1: json: cannot unmarshal string into Go struct field .F.V of type int
v2: json: cannot unmarshal string into Go struct field S.F.V of type int

For reasons unclear, the v1 logic was always inconsistent about
whether it could properly record the root struct type,
while the v1 emulation layer under v2 is always able to.

This only modifies code that is compiled in under goexperiment.jsonv2.

Fixes #74713

Change-Id: I9e87323b1810130cb929288fdd86aff4be82d5f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/689918
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

time: remove redundant uint32 conversion in split

cd is a uint32 converted again.

Change-Id: Ia41e247e0644c17cd9e0593d79457db77512fc3e
GitHub-Last-Rev: 1ba8596e2761be75cc35f79e8245a96d6bb81096
GitHub-Pull-Request: golang/go#74679
Reviewed-on: https://go-review.googlesource.com/c/go/+/689055
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

internal/buildcfg: add ability to get GORISCV64 variable in GOGOARCH

For #61476

Change-Id: I29f4c1c3c3303e70ec2d7f380112eb2d00754018
Reviewed-on: https://go-review.googlesource.com/c/go/+/665655
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>

cmd/internal/obj: rip out argp adjustment for wrapper frames

The previous CL made this adjustment unnecessary. The argp field
is no longer used by the runtime.

Change-Id: I3491eeef4103c6653ec345d604c0acd290af9e8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/685356
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>

runtime: detect successful recovers differently

Use stack unwinding instead of keeping incremental track of the argp
of defers that are allowed to recover.

It's much simpler, and it lets us get rid of the incremental tracking
by wrapper code. (Ripped out in a subsequent CL.)

We only need to stack unwind a few frames to get the right answer, and
only when recover()ing in a panic situation. It will be more expensive
in that case, but cheaper in all others.

Change-Id: Id095807db6864b7ac1e1baf09285b77a07c46d19
Reviewed-on: https://go-review.googlesource.com/c/go/+/685355
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>

unicode/utf8: skip ahead during ascii runs in Valid/ValidString

When we see an ASCII character, we will probably see many.
Grab & check increasingly large chunks of the string for ASCII-only-ness.

Also redo some of the non-ASCII code to make it more optimizer friendly.

goos: linux
goarch: amd64
pkg: unicode/utf8
cpu: 12th Gen Intel(R) Core(TM) i7-12700
                               │     base     │                 exp                 │
                               │    sec/op    │   sec/op     vs base                │
ValidTenASCIIChars-20             3.596n ± 3%   2.522n ± 1%  -29.86% (p=0.000 n=10)
Valid100KASCIIChars-20            6.094µ ± 2%   2.115µ ± 1%  -65.29% (p=0.000 n=10)
ValidTenJapaneseChars-20          21.02n ± 0%   18.61n ± 2%  -11.44% (p=0.000 n=10)
ValidLongMostlyASCII-20          51.774µ ± 0%   3.836µ ± 1%  -92.59% (p=0.000 n=10)
ValidLongJapanese-20             102.40µ ± 1%   50.95µ ± 1%  -50.24% (p=0.000 n=10)
ValidStringTenASCIIChars-20       2.640n ± 3%   2.526n ± 1%   -4.34% (p=0.000 n=10)
ValidString100KASCIIChars-20      5.585µ ± 7%   2.118µ ± 1%  -62.07% (p=0.000 n=10)
ValidStringTenJapaneseChars-20    21.29n ± 2%   18.67n ± 1%  -12.31% (p=0.000 n=10)
ValidStringLongMostlyASCII-20    52.431µ ± 1%   3.841µ ± 0%  -92.67% (p=0.000 n=10)
ValidStringLongJapanese-20       102.66µ ± 1%   50.90µ ± 1%  -50.42% (p=0.000 n=10)
geomean                           1.152µ        454.8n       -60.53%

This is an attempt to see if we can get enough performance that we don't
need to consider assembly like that in CL 681695.

Change-Id: I8250feb797a6b4e7d335c23929f6e3acc8b24840
Reviewed-on: https://go-review.googlesource.com/c/go/+/682778
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: move amd64 and 386 over to new bounds check strategy

Change-Id: I13f54f04ccb8452e625dba4249e0d56bafd1fad8
Reviewed-on: https://go-review.googlesource.com/c/go/+/682397
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

cmd/compile: add missing StringLen rule in prove

(StringLen (StringMake _ x)) == x, just like the rules we
currently have for slices.

This helps propagate string length knowledge to places which need it.

Change-Id: Ifdcf6d1f2d430c1c4bbac32e0ea74c188eae998e
Reviewed-on: https://go-review.googlesource.com/c/go/+/682777
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
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@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>

cmd/compile: move arm64 over to new bounds check strategy

For all the static bounds checks in cmd/go, we have:

    6877    just a single instruction (the call itself)
    139     needs an additional reg-reg move
    602     needs an additional constant load
    25      needs some other instruction

that's ~90% implemented using just a single instruction.

Reduces the text size of cmd/go by ~0.8%.
Total binary size is just barely smaller, ~0.2%. (The difference
is the new pcdata table.)

Change-Id: I416e9c196f5d8d0e8f08e191e6df3045e11dccbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/682496
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/compile,runtime: remember idx+len for bounds check failure with less code

Currently we must put the index and length into specific registers so
we can call into the runtime to report a bounds check failure.

So a typical bounds check call is something like:

MOVD  R3, R0
MOVD  R7, R1
CALL  runtime.panicIndex

or, if for instance the index is constant,

MOVD  $7, R0
MOVD  R9, R1
CALL  runtime.panicIndex

Sometimes the MOVD can be avoided, if the value happens to be in the
right register already. But that's not terribly common, and doesn't
work at all for constants.

Let's get rid of those MOVD instructions. They pollute the instruction
cache and are almost never executed.

Instead, we'll encode in a PCDATA table where the runtime should find
the index and length. The table encodes, for each index and length,
whether it is a constant or in a register, and which register or
constant it is.

That way, we can avoid all those useless MOVDs. Instead, we can figure
out the index and length at runtime. This makes the bounds panic path
slower, but that's a good tradeoff.

We can encode registers 0-15 and constants 0-31. Anything outside that
range still needs to use an explicit instruction.

This CL is the foundation, followon CLs will move each architecture
to the new strategy.

Change-Id: I705c511e546e6aac59fed922a8eaed4585e96820
Reviewed-on: https://go-review.googlesource.com/c/go/+/682396
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: move bounds check constants to internal/abi

For future use by the compiler.

Change-Id: Id3da62006b283ac38008261c0ef88aaf71ef5896
Reviewed-on: https://go-review.googlesource.com/c/go/+/682456
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/compile: rewrite condselects into doublings and halvings

For performance see CL 685676.

This allows something like:
  if y { x *= 2 }

To be compiled to:
  SHLXQ BX, AX, AX

Instead of:
  MOVQ    AX, CX
  SHLQ    $1, CX
  MOVBLZX BL, DX
  TESTQ   DX, DX
  CMOVQNE CX, AX

While ./make.bash uniqued per LOC, there is 2 doublings and 4 halvings.

Change-Id: Ic0727cbf429528a2dbf17cbfc3b0121db8387444
Reviewed-on: https://go-review.googlesource.com/c/go/+/685695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

cmd/compile: add opt branchelim to rewrite some CondSelect into math

This allows something like:
  if y { x++ }

To be compiled to:
  MOVBLZX BX, CX
  ADDQ CX, AX

Instead of:
  LEAQ    1(AX), CX
  MOVBLZX BL, DX
  TESTQ   DX, DX
  CMOVQNE CX, AX

While ./make.bash uniqued per LOC, there is 100 additions and 75 substractions.

See benchmark here: https://go.dev/play/p/DJf5COjwhd_s

Either it's a performance no-op or it is faster:

  goos: linux
  goarch: amd64
  cpu: AMD Ryzen 5 3600 6-Core Processor
                                          │ /tmp/old.logs │            /tmp/new.logs             │
                                          │    sec/op     │    sec/op     vs base                │
  CmovInlineConditionAddLatency-12           0.5443n ± 5%   0.5339n ± 3%   -1.90% (p=0.004 n=10)
  CmovInlineConditionAddThroughputBy6-12      1.492n ± 1%    1.494n ± 1%        ~ (p=0.955 n=10)
  CmovInlineConditionSubLatency-12           0.5419n ± 3%   0.5282n ± 3%   -2.52% (p=0.019 n=10)
  CmovInlineConditionSubThroughputBy6-12      1.587n ± 1%    1.584n ± 2%        ~ (p=0.492 n=10)
  CmovOutlineConditionAddLatency-12          0.5223n ± 1%   0.2639n ± 4%  -49.47% (p=0.000 n=10)
  CmovOutlineConditionAddThroughputBy6-12     1.159n ± 1%    1.097n ± 2%   -5.35% (p=0.000 n=10)
  CmovOutlineConditionSubLatency-12          0.5271n ± 3%   0.2654n ± 2%  -49.66% (p=0.000 n=10)
  CmovOutlineConditionSubThroughputBy6-12     1.053n ± 1%    1.050n ± 1%        ~ (p=1.000 n=10)
  geomean

There are other benefits not tested by this benchmark:
- the math form is usually a couple bytes shorter (ICACHE)
- the math form is usually 0~2 uops shorter (UCACHE)
- the math form has usually less register pressure*
- the math form can sometimes be optimized further

*regalloc rarely find how it can use less registers

As far as pass ordering goes there are many possible options,
I've decided to reorder branchelim before late opt since:
- unlike running exclusively the CondSelect rules after branchelim,
  some extra optimizations might trigger on the adds or subs.
- I don't want to maintain a second generic.rules file of only the stuff,
  that can trigger after branchelim.
- rerunning all of opt a third time increase compilation time for little gains.

By elimination moving branchelim seems fine.

Change-Id: I869adf57e4d109948ee157cfc47144445146bafd
Reviewed-on: https://go-review.googlesource.com/c/go/+/685676
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: Michael Knyszek <mknyszek@google.com>

cmd/compile: learn transitive proofs for safe unsigned subs

I've split this into it's own CL to make git bisect more effective.

Change-Id: I436ff21a3e2362b3924de25a458534eb9947e013
Reviewed-on: https://go-review.googlesource.com/c/go/+/685821
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

cmd/compile: learn transitive proofs for safe negative signed adds

I've split this into it's own CL to make git bisect more effective.

Change-Id: Ib2c6dbc82fb04f50f2d17fbe6626c9fc322fb478
Reviewed-on: https://go-review.googlesource.com/c/go/+/685820
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/compile: learn transitive proofs for safe positive signed adds

I've split this into it's own CL to make git bisect more effective.

Change-Id: I3fbb42ec7d29169a29f7f55ef2c188317512f532
Reviewed-on: https://go-review.googlesource.com/c/go/+/685819
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: learn transitive proofs for safe unsigned adds

I've split this into it's own CL to make git bisect more effective.

Change-Id: Iaab5f0bd2ad51e86ced8c6b8fbd371eb75eeef14
Reviewed-on: https://go-review.googlesource.com/c/go/+/685815
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>

cmd/compile: fold shift through AND for slice operations

Fold a shift through AND when the AND gets a zero-or-one operand (e.g.
from arithmetic shift by 63 of a 64-bit value) for a common case with
slice operations:

    ASR     $63, R2, R2
    AND     R3<<3, R2, R2
    ADD     R2, R0, R2

As the operands are 64-bit, we can transform it to:

    AND     R2->63, R3, R2
    ADD     R2<<3, R0, R2

Code size improvement:
compile: .text:     9088004 ->  9086292 (-0.02%)
etcd:    .text:    10500276 -> 10498964 (-0.01%)

Change-Id: Ibcd5e67173da39b77ceff77ca67812fb8be5a7b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/679895
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

internal/runtime/syscall: rename to internal/runtime/syscall/linux

All code in internal/runtime/syscall is Linux-specific, so better
move it to a new linux sub-directory. This way it will be easier
to factor out runtime syscall code from other platforms, e.g.
Windows.

Updates #51087.

Change-Id: Idd2a52444b33bf3ad576b47fd232e990cdc8ae75
Reviewed-on: https://go-review.googlesource.com/c/go/+/689155
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: improve loopRotate to handle nested loops

Enhance loop rotation of nested loops. Currently, loops are processed independently,
resulting in unnecessary jumps between outer and inner loops. By processing inner
loops before their parent loop, we ensure nested loop blocks are
properly placed within their parent loop's block sequence.

There is some code size improvement (as measured on amd64) due to jumps
to/from inner loop are removed by the updated loopRotate block order:

Executable            Old .text  New .text     Change
-------------------------------------------------------
asm                     2147569    2146481     -0.05%
cgo                     1977457    1975761     -0.09%
compile                10447345   10441905     -0.05%
cover                   2110097    2108977     -0.05%
link                    2930289    2929041     -0.04%
preprofile               927345     926769     -0.06%
vet                     3279057    3277009     -0.06%

Change-Id: I4b9e993c2be07fad735e6bcf32d062d099d9cfb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/684335
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: optimize slice bounds checking with SUB/SUBconst comparisons

Optimize ARM64 code generation for slice bounds checking by recognizing
patterns where comparisons to zero involve SUB or SUBconst operations.
This change adds SSA opt rules to simplify:
 (CMPconst [0] (SUB x y)) => (CMP x y)

The optimizations apply to EQ, NE, ULE, and UGT comparisons, enabling
more efficient bounds checking for slice operations.

Code size improvement:
compile: .text:    9088004  ->  9065988 (-0.24%)
etcd:    .text:    10500276 -> 10497092 (-0.03%)
Change-Id: I467cb27674351652bcacc52b87e1f19677bd46a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/679915
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>

internal/poll: remove handle field from Windows' poll.operation

The handle field can be accessed directly wherever needed, there is
no need to store it in the operation struct.

This skims down the size of os.File by 16 bytes.

Change-Id: I87c94cb773437891127b6c36dc7f8883622ffed3
Reviewed-on: https://go-review.googlesource.com/c/go/+/685435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>

internal/poll: remove fd field from Windows' poll.operation

There is no need to keep the fd in the poll.operation struct,
given that all usages of this field have direct access to the fd struct.

This skims down the size of os.File by 16 bytes.

Change-Id: I837e345250387f62e294cc1772d752865a04ef6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/685415
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

runtime: add benchmark for small-size memmory operation

On RISC-V and MIPS andarchitectures, misaligned load/store is not mandatory for implementations. Therefore, it's important to handle memory operations involving small sizes or data with a remainder when divided by 8 or 4.
This CL add some benchmark for small-size memmory operation, to ensure that SSA rules do not generate unaligned access traps on such architectures.

Change-Id: I6fcdfdb76e9552d5b10df140fa92568ac9468386
Reviewed-on: https://go-review.googlesource.com/c/go/+/682575
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>

hash/crc32: add AVX512 IEEE CRC32 calculation

Benchmark:

goos: windows
goarch: amd64
pkg: hash/crc32
cpu: AMD Ryzen 9 9950X 16-Core Processor

benchmark                                               old MB/s     new MB/s     speedup
BenchmarkCRC32/poly=IEEE/size=15/align=0-32             1081.48      1089.42      1.01x
BenchmarkCRC32/poly=IEEE/size=15/align=1-32             1085.87      1082.61      1.00x
BenchmarkCRC32/poly=IEEE/size=40/align=0-32             2756.33      2752.37      1.00x
BenchmarkCRC32/poly=IEEE/size=40/align=1-32             2758.27      2756.99      1.00x
BenchmarkCRC32/poly=IEEE/size=512/align=0-32            18133.44     18076.52     1.00x
BenchmarkCRC32/poly=IEEE/size=512/align=1-32            18151.05     18055.41     0.99x
BenchmarkCRC32/poly=IEEE/size=1kB/align=0-32            19902.93     48581.07     2.44x
BenchmarkCRC32/poly=IEEE/size=1kB/align=1-32            19966.99     48393.25     2.42x
BenchmarkCRC32/poly=IEEE/size=4kB/align=0-32            21690.33     51679.25     2.38x
BenchmarkCRC32/poly=IEEE/size=4kB/align=1-32            21655.30     51731.22     2.39x
BenchmarkCRC32/poly=IEEE/size=32kB/align=0-32           22046.57     46406.90     2.10x
BenchmarkCRC32/poly=IEEE/size=32kB/align=1-32           21986.22     46250.66     2.10x

AVX512 are enabled above 1KB input size.

This rather high limit is due to AVX512 may be slower to ramp up
than the regular SSE4 implementation for smaller inputs.

This is not reflected in the benchmarks,
since consecutive calls means the CPU is "hot".

The 'HasAVX512VPCLMULQDQ' name mirrors the one in golang.org/x/sys/cpu

Change-Id: Id23685d8e3cc412b6d397a7d70056844bdb79271

Change-Id: Id23685d8e3cc412b6d397a7d70056844bdb79271
GitHub-Last-Rev: 6639f07b9febc7c96a7f3b402a2fd60f7be5e154
GitHub-Pull-Request: golang/go#74701
Reviewed-on: https://go-review.googlesource.com/c/go/+/689435
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

cmd/compile: prefer base.Fatalf to panic in dwarfgen

Updates a few spots which call `panic` to instead call `base.Fatalf`.

Change-Id: I30b73c7994caa647245b0e253f20e0b88185e644
GitHub-Last-Rev: b3839bbe424294f92a1f9448e5e0ac074e722e4d
GitHub-Pull-Request: golang/go#74616
Reviewed-on: https://go-review.googlesource.com/c/go/+/688035
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/internal/obj/s390x: add MVCLE instruction

MVCLE (Move Long Extended) instruction is used to move large data storage-to-storage.
This change will add MVCLE into the Go asm for s390x architecture.
Upcoming PR of runtime/memmove_s390x.s will use this instruction for performance improvement.

Change-Id: I3bbb6668c736a36849917887398c74cebb1c3a99
Reviewed-on: https://go-review.googlesource.com/c/go/+/677455
Reviewed-by: Srinivas Pokala <Pokala.Srinivas@ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Munday <mikemndy@gmail.com>
Reviewed-by: Vishwanatha HD <vishwanatha.hd@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

runtime: optimize memclr on mips64x

Memclr/5-4                          49.94n ±  5%         50.51n ±  1%        ~ (p=0.331 n=6)
Memclr/16-4                         22.71n ±  0%         21.01n ±  2%   -7.47% (p=0.002 n=6)
Memclr/64-4                         49.70n ±  1%         26.09n ±  1%  -47.51% (p=0.002 n=6)
Memclr/256-4                        84.23n ±  3%         44.32n ±  2%  -47.38% (p=0.002 n=6)
Memclr/4096-4                       805.6n ±  1%         220.9n ±  2%  -72.57% (p=0.002 n=6)
Memclr/65536-4                     12.734µ ±  1%         3.287µ ±  1%  -74.19% (p=0.002 n=6)
Memclr/1M-4                         209.1µ ±  0%         105.9µ ±  5%  -49.34% (p=0.002 n=6)
Memclr/4M-4                         838.9µ ±  6%         418.2µ ±  0%  -50.15% (p=0.002 n=6)
Memclr/8M-4                         1.708m ±  4%         1.108m ±  4%  -35.15% (p=0.002 n=6)
Memclr/16M-4                        3.458m ±  1%         2.840m ±  3%  -17.88% (p=0.002 n=6)
Memclr/64M-4                        14.05m ±  0%         11.40m ±  2%  -18.87% (p=0.002 n=6)
MemclrUnaligned/0_5-4               50.57n ±  2%         51.00n ±  0%        ~ (p=0.063 n=6)
MemclrUnaligned/0_16-4              48.82n ±  8%         22.39n ±  1%  -54.14% (p=0.002 n=6)
MemclrUnaligned/0_64-4              52.73n ±  3%         25.29n ±  0%  -52.05% (p=0.002 n=6)
MemclrUnaligned/0_256-4             88.41n ±  1%         50.04n ±  7%  -43.41% (p=0.002 n=6)
MemclrUnaligned/0_4096-4            802.2n ±  1%         220.4n ±  1%  -72.53% (p=0.002 n=6)
MemclrUnaligned/0_65536-4          12.729µ ±  0%         3.341µ ±  6%  -73.76% (p=0.002 n=6)
MemclrUnaligned/1_5-4               50.52n ±  0%         50.99n ±  6%   +0.93% (p=0.002 n=6)
MemclrUnaligned/1_16-4              71.23n ±  1%         71.78n ±  1%   +0.77% (p=0.041 n=6)
MemclrUnaligned/1_64-4              85.11n ±  0%         76.30n ±  1%  -10.36% (p=0.002 n=6)
MemclrUnaligned/1_256-4            133.50n ±  2%         91.91n ±  1%  -31.15% (p=0.002 n=6)
MemclrUnaligned/1_4096-4            849.7n ±  0%         291.3n ±  2%  -65.72% (p=0.002 n=6)
MemclrUnaligned/1_65536-4          12.776µ ±  1%         3.399µ ±  1%  -73.40% (p=0.002 n=6)
MemclrUnaligned/4_5-4               44.34n ±  0%         44.52n ±  7%   +0.41% (p=0.022 n=6)
MemclrUnaligned/4_16-4              70.68n ±  0%         71.24n ±  4%        ~ (p=0.132 n=6)
MemclrUnaligned/4_64-4              81.83n ±  4%         77.98n ±  2%   -4.71% (p=0.002 n=6)
MemclrUnaligned/4_256-4            121.15n ±  3%         87.58n ±  0%  -27.71% (p=0.002 n=6)
MemclrUnaligned/4_4096-4            837.0n ±  2%         278.8n ±  3%  -66.69% (p=0.002 n=6)
MemclrUnaligned/4_65536-4          12.793µ ±  6%         3.373µ ±  3%  -73.64% (p=0.002 n=6)
MemclrUnaligned/7_5-4               43.89n ±  2%         43.10n ±  0%   -1.80% (p=0.002 n=6)
MemclrUnaligned/7_16-4              73.59n ±  2%         72.95n ±  1%   -0.86% (p=0.006 n=6)
MemclrUnaligned/7_64-4              88.67n ±  0%         78.89n ±  1%  -11.03% (p=0.002 n=6)
MemclrUnaligned/7_256-4            123.90n ±  1%         85.41n ±  2%  -31.07% (p=0.002 n=6)
MemclrUnaligned/7_4096-4            842.8n ±  2%         268.0n ±  0%  -68.20% (p=0.002 n=6)
MemclrUnaligned/7_65536-4          12.877µ ± 11%         3.348µ ±  0%  -74.00% (p=0.002 n=6)
MemclrUnaligned/0_1M-4              208.4µ ±  5%         104.6µ ±  1%  -49.80% (p=0.002 n=6)
MemclrUnaligned/0_4M-4              836.1µ ±  7%         419.3µ ±  2%  -49.85% (p=0.002 n=6)
MemclrUnaligned/0_8M-4              1.701m ±  9%         1.136m ± 12%  -33.21% (p=0.002 n=6)
MemclrUnaligned/0_16M-4             3.467m ± 16%         2.832m ±  4%  -18.30% (p=0.002 n=6)
MemclrUnaligned/0_64M-4             14.05m ±  2%         11.33m ±  2%  -19.38% (p=0.002 n=6)
MemclrUnaligned/1_1M-4              208.8µ ±  4%         104.7µ ±  1%  -49.85% (p=0.002 n=6)
MemclrUnaligned/1_4M-4              838.0µ ±  0%         418.3µ ±  2%  -50.09% (p=0.002 n=6)
MemclrUnaligned/1_8M-4              1.692m ±  1%         1.108m ±  3%  -34.53% (p=0.002 n=6)
MemclrUnaligned/1_16M-4             3.463m ± 20%         2.833m ±  6%  -18.21% (p=0.002 n=6)
MemclrUnaligned/1_64M-4             14.05m ±  4%         11.35m ±  2%  -19.28% (p=0.002 n=6)
MemclrUnaligned/4_1M-4              209.2µ ±  1%         104.7µ ±  7%  -49.94% (p=0.002 n=6)
MemclrUnaligned/4_4M-4              836.2µ ±  6%         418.8µ ± 15%  -49.91% (p=0.002 n=6)
MemclrUnaligned/4_8M-4              1.702m ±  0%         1.123m ±  4%  -34.01% (p=0.002 n=6)
MemclrUnaligned/4_16M-4             3.476m ±  8%         2.804m ±  2%  -19.34% (p=0.002 n=6)
MemclrUnaligned/4_64M-4             14.13m ± 25%         11.40m ±  0%  -19.33% (p=0.002 n=6)
MemclrUnaligned/7_1M-4              208.9µ ±  8%         104.9µ ±  6%  -49.81% (p=0.002 n=6)
MemclrUnaligned/7_4M-4              845.6µ ± 12%         418.2µ ±  7%  -50.54% (p=0.002 n=6)
MemclrUnaligned/7_8M-4              1.706m ± 10%         1.101m ±  3%  -35.48% (p=0.002 n=6)
MemclrUnaligned/7_16M-4             3.466m ±  3%         2.812m ±  2%  -18.86% (p=0.002 n=6)
MemclrUnaligned/7_64M-4             14.08m ±  5%         11.35m ± 18%  -19.37% (p=0.002 n=6)
GoMemclr/5-4                        49.79n ±  2%         50.34n ±  0%        ~ (p=0.394 n=6)
GoMemclr/16-4                       21.64n ±  0%         22.04n ±  7%   +1.85% (p=0.002 n=6)
GoMemclr/64-4                       47.93n ±  4%         23.77n ±  4%  -50.41% (p=0.002 n=6)
GoMemclr/256-4                      82.77n ±  2%         43.90n ±  0%  -46.96% (p=0.002 n=6)

Change-Id: I272967d001809ac4948e4118df6cdd0e0661ab96
Reviewed-on: https://go-review.googlesource.com/c/go/+/682195
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: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

runtime: improvement in memclr for s390x

The unrolled loop for sizes >= 4KB is further optimized.
Offsets are computed and included in the XC instruction directly.
This reduces code size and instructions, improves performance.

goos: linux
goarch: s390x
pkg: runtime
                        | Orig_Memclr_for_benchstat_2.log | MM_Memclr_for_benchstat_No_VSTL_3.log  |
                        |             sec/op              |    sec/op     vs base                  |
Memclr/5                                     1.925n ±  0%   1.925n ±  0%        ~ (p=0.211 n=10)
Memclr/16                                    2.604n ± 13%   2.633n ± 11%        ~ (p=0.912 n=10)
Memclr/64                                    3.598n ±  2%   3.520n ±  5%        ~ (p=0.190 n=10)
Memclr/256                                   3.571n ± 12%   3.538n ± 11%        ~ (p=0.739 n=10)
Memclr/4096                                  15.15n ±  0%   15.14n ±  0%        ~ (p=0.204 n=10)
Memclr/65536                                 226.3n ±  0%   224.9n ±  0%   -0.62% (p=0.000 n=10)
Memclr/1M                                    12.77µ ±  0%   12.60µ ±  0%   -1.35% (p=0.000 n=10)
Memclr/4M                                    51.07µ ±  0%   50.37µ ±  0%   -1.38% (p=0.000 n=10)
Memclr/8M                                    102.1µ ±  0%   100.7µ ±  0%   -1.36% (p=0.000 n=10)
Memclr/16M                                   204.4µ ±  0%   201.6µ ±  0%   -1.35% (p=0.000 n=10)
Memclr/64M                                   965.4µ ±  0%   935.3µ ±  0%   -3.12% (p=0.000 n=10)
MemclrUnaligned/0_5                          2.671n ±  6%   2.618n ±  0%        ~ (p=0.194 n=10)
MemclrUnaligned/0_16                         3.143n ±  6%   2.955n ±  8%        ~ (p=0.089 n=10)
MemclrUnaligned/0_64                         3.622n ±  3%   3.571n ±  2%        ~ (p=0.304 n=10)
MemclrUnaligned/0_256                        3.712n ±  8%   3.653n ±  5%        ~ (p=0.754 n=10)
MemclrUnaligned/0_4096                       15.14n ±  0%   15.14n ±  0%        ~ (p=1.000 n=10) ¹
MemclrUnaligned/0_65536                      231.9n ±  0%   225.2n ±  0%   -2.91% (p=0.000 n=10)
MemclrUnaligned/1_5                          2.620n ±  8%   2.620n ±  0%        ~ (p=0.866 n=10)
MemclrUnaligned/1_16                         3.103n ±  7%   2.933n ±  9%        ~ (p=0.052 n=10)
MemclrUnaligned/1_64                         3.576n ±  3%   3.568n ±  3%        ~ (p=0.748 n=10)
MemclrUnaligned/1_256                        3.744n ±  9%   3.709n ± 10%        ~ (p=0.853 n=10)
MemclrUnaligned/1_4096                       26.23n ±  0%   26.23n ±  0%        ~ (p=1.000 n=10) ¹
MemclrUnaligned/1_65536                      401.1n ±  0%   399.5n ±  0%   -0.40% (p=0.000 n=10)
MemclrUnaligned/4_5                          2.620n ±  6%   2.623n ±  0%        ~ (p=0.985 n=10)
MemclrUnaligned/4_16                         3.095n ±  7%   3.005n ±  9%        ~ (p=0.247 n=10)
MemclrUnaligned/4_64                         3.586n ±  1%   3.578n ±  3%        ~ (p=1.000 n=10)
MemclrUnaligned/4_256                        3.843n ±  5%   3.742n ± 10%        ~ (p=0.971 n=10)
MemclrUnaligned/4_4096                       26.23n ±  0%   26.23n ±  0%        ~ (p=1.000 n=10)
MemclrUnaligned/4_65536                      401.1n ±  0%   399.5n ±  0%   -0.41% (p=0.000 n=10)
MemclrUnaligned/7_5                          2.634n ±  6%   2.644n ±  4%        ~ (p=0.896 n=10)
MemclrUnaligned/7_16                         3.119n ±  7%   3.044n ±  9%        ~ (p=0.529 n=10)
MemclrUnaligned/7_64                         3.568n ±  1%   3.585n ±  3%        ~ (p=0.499 n=10)
MemclrUnaligned/7_256                        3.741n ±  9%   3.629n ±  6%        ~ (p=0.853 n=10)
MemclrUnaligned/7_4096                       26.23n ±  0%   26.23n ±  0%        ~ (p=1.000 n=10) ¹
MemclrUnaligned/7_65536                      401.1n ±  0%   399.4n ±  0%   -0.42% (p=0.000 n=10)
MemclrUnaligned/0_1M                         12.82µ ±  0%   12.60µ ±  0%   -1.70% (p=0.000 n=10)
MemclrUnaligned/0_4M                         51.28µ ±  0%   50.37µ ±  0%   -1.77% (p=0.000 n=10)
MemclrUnaligned/0_8M                         102.5µ ±  0%   100.8µ ±  0%   -1.75% (p=0.000 n=10)
MemclrUnaligned/0_16M                        205.1µ ±  0%   201.7µ ±  0%   -1.62% (p=0.000 n=10)
MemclrUnaligned/0_64M                        965.2µ ±  0%   934.7µ ±  0%   -3.16% (p=0.000 n=10)
MemclrUnaligned/1_1M                         16.02µ ±  0%   15.81µ ±  0%   -1.34% (p=0.000 n=10)
MemclrUnaligned/1_4M                         64.03µ ±  0%   63.20µ ±  0%   -1.29% (p=0.000 n=10)
MemclrUnaligned/1_8M                         128.0µ ±  0%   126.4µ ±  0%   -1.27% (p=0.000 n=10)
MemclrUnaligned/1_16M                        256.3µ ±  0%   253.2µ ±  0%   -1.21% (p=0.000 n=10)
MemclrUnaligned/1_64M                        1.210m ±  0%   1.187m ±  0%   -1.88% (p=0.000 n=10)
MemclrUnaligned/4_1M                         16.03µ ±  0%   15.81µ ±  0%   -1.37% (p=0.000 n=10)
MemclrUnaligned/4_4M                         64.04µ ±  0%   63.20µ ±  0%   -1.31% (p=0.000 n=10)
MemclrUnaligned/4_8M                         128.0µ ±  0%   126.4µ ±  0%   -1.27% (p=0.000 n=10)
MemclrUnaligned/4_16M                        256.1µ ±  0%   253.0µ ±  0%   -1.20% (p=0.000 n=10)
MemclrUnaligned/4_64M                        1.210m ±  0%   1.188m ±  0%   -1.81% (p=0.000 n=10)
MemclrUnaligned/7_1M                         16.02µ ±  0%   15.81µ ±  0%   -1.32% (p=0.000 n=10)
MemclrUnaligned/7_4M                         64.06µ ±  0%   63.21µ ±  0%   -1.34% (p=0.000 n=10)
MemclrUnaligned/7_8M                         128.1µ ±  0%   126.4µ ±  0%   -1.29% (p=0.000 n=10)
MemclrUnaligned/7_16M                        256.2µ ±  0%   253.2µ ±  0%   -1.18% (p=0.000 n=10)
MemclrUnaligned/7_64M                        1.210m ±  0%   1.188m ±  0%   -1.82% (p=0.000 n=10)
MemclrRange/1K_2K                            841.1n ±  1%   879.0n ±  3%   +4.51% (p=0.002 n=10)
MemclrRange/2K_8K                            1.435µ ±  2%   1.415µ ±  0%   -1.39% (p=0.000 n=10)
MemclrRange/4K_16K                           1.241µ ±  0%   1.209µ ±  0%   -2.58% (p=0.000 n=10)
MemclrRange/160K_228K                        19.83µ ±  0%   19.59µ ±  0%   -1.22% (p=0.000 n=10)
MemclrKnownSize1                             1.732n ±  0%   1.732n ±  0%        ~ (p=0.474 n=10)
MemclrKnownSize2                             1.925n ±  3%   1.925n ±  1%        ~ (p=0.929 n=10)
MemclrKnownSize4                             1.732n ±  0%   1.732n ±  0%        ~ (p=1.000 n=10) ¹
MemclrKnownSize8                             1.732n ±  0%   1.732n ±  0%        ~ (p=1.000 n=10)
MemclrKnownSize16                            2.413n ±  9%   2.681n ± 14%  +11.10% (p=0.004 n=10)
MemclrKnownSize32                            3.284n ±  4%   3.328n ±  2%        ~ (p=0.671 n=10)
MemclrKnownSize64                            4.893n ±  1%   4.882n ±  1%        ~ (p=0.591 n=10)
MemclrKnownSize112                           5.623n ±  2%   5.596n ±  2%   -0.48% (p=0.027 n=10)
MemclrKnownSize128                           5.612n ±  1%   5.599n ±  0%        ~ (p=0.066 n=10)
MemclrKnownSize192                           7.128n ±  1%   7.337n ±  2%   +2.93% (p=0.000 n=10)
MemclrKnownSize248                           6.740n ±  1%   6.829n ±  3%   +1.33% (p=0.005 n=10)
MemclrKnownSize256                           3.657n ±  8%   3.512n ± 14%        ~ (p=0.436 n=10)
MemclrKnownSize512                           3.624n ±  3%   3.982n ±  9%   +9.88% (p=0.017 n=10)
MemclrKnownSize1024                          4.662n ±  0%   4.680n ±  0%   +0.39% (p=0.000 n=10)
MemclrKnownSize4096                          15.14n ±  0%   15.15n ±  0%   +0.07% (p=0.000 n=10)
MemclrKnownSize512KiB                        6.388µ ±  0%   6.309µ ±  0%   -1.24% (p=0.000 n=10)
geomean                                      268.9n         266.9n         -0.75%
¹ all samples are equal

Change-Id: I2911866fb82777311ec4219600fb48c85f7bf862
Reviewed-on: https://go-review.googlesource.com/c/go/+/682595
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

internal/runtime/exithook: fix a typo

That is the say -> That is to say

Change-Id: I4a19d4c500103e16e6ae55f41a9fbdddd4bb84a8
GitHub-Last-Rev: 571d49ab8e6d81ac9db8b47d89118fb74bd3f2f6
GitHub-Pull-Request: golang/go#74741
Reviewed-on: https://go-review.googlesource.com/c/go/+/690195
Reviewed-by: Michael Knyszek <mknyszek@google.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>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

cmd/internal/goobj: make error output clear

Change-Id: Ic8510037e5d745f3c9f1b9c203439d3fe2e2d5a5
GitHub-Last-Rev: 4101a1595bd542bec8c20e4332c884125ee57aff
GitHub-Pull-Request: golang/go#74703
Reviewed-on: https://go-review.googlesource.com/c/go/+/689515
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go/internal/doc: clean up after merge with cmd/internal/doc

This is done in a separate CL to reduce the diffs from the previous CL.
Merge the main.go and doc.go files, and isolate the bootstrap-tagged
code to one file.

For #74667

Change-Id: I11bf0aa18beeb898937135f49f473c1ba1b7e756
Reviewed-on: https://go-review.googlesource.com/c/go/+/689875
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

cmd/internal/doc: merge with cmd/go/internal/doc

Now that cmd/doc has been removed, cmd/go/internal/doc is the only user
of the cmd/internal/doc code. Merge cmd/internal/doc into
cmd/go/internal/doc.

For #74667

Change-Id: I16bbe7b1f418b54ee411c8d6e6609c0973e40b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/689836
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/doc: delete

Users should not invoke "go tool doc" directly, but should instead run
"go doc". Remove "cmd/doc" because it no longer invokes the "doc" tool
but incorporates its logic directly.

Fixes #74667

Change-Id: I357a3d7e0ca075f028df66e34951a41354c08941
Reviewed-on: https://go-review.googlesource.com/c/go/+/689835
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: randomize heap base address

During initialization, allow randomizing the heap base address by
generating a random uint64 and using its bits to randomize various
portions of the heap base address.

We use the following method to randomize the base address:

* We first generate a random heapArenaBytes aligned address that we use
  for generating the hints.
* On the first call to mheap.grow, we then generate a random
  PallocChunkBytes aligned offset into the mmap'd heap region, which we
  use as the base for the heap region.
* We then mark a random number of pages within the page allocator as
  allocated.

Our final randomized "heap base address" becomes the first byte of
the first available page returned by the page allocator. This results
in an address with at least heapAddrBits-gc.PageShift-1 bits of
entropy.

Fixes #27583

Change-Id: Ideb4450a5ff747a132f702d563d2a516dec91a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/674835
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: use better fatal message for staticValue1

So the position of the wrong assignment statement will be reported,
instead of using incorrect base.Pos one.

Notice while fixing issue #73823.

Change-Id: I53f240bf99d11b5f5082ee4ca0903d9f099881b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/675495
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>

cmd/cgo: compare malloc return value to NULL instead of literal 0

Follow the pattern used in the other _cgoPREFIX_Cfunc* functions. This
also avoids a -Wzero-as-null-pointer-constant warning when compiling
with g++.

Change-Id: I95ac8842df048105f4c738f3603136d9cfa2dfdc
Reviewed-on: https://go-review.googlesource.com/c/go/+/664916
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>

go/types, types2: better error messages for certain type mismatches

When an untyped operand of a (typically binary) operation does not
match the type of the operand and an implicit conversion is not
possible, the error message should report a "type mismatch".

The type-checkers mostly did so, but not for untyped numeric types
to other types (e.g. an untyped int vs a function); in those cases
it reported that the (impossible) conversion failed.

Fix this for numeric types.
This also improves the position and messages for some incorrect
min/max built-in calls.

Fixes #73428.

Change-Id: I8af071918b73fcc72f16cc61858d7baca57fc259
Reviewed-on: https://go-review.googlesource.com/c/go/+/682495
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>

cmd/compile: use ,ok return idiom for sparsemap.get

Change-Id: I89719b94de74a32402d02309515dffc4989484db
Reviewed-on: https://go-review.googlesource.com/c/go/+/681575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>

cmd/compile: use generics for sparse map

So it is easier to reuse this code with different key/value types.

Change-Id: I5a9e669769cf359b32f2fe784594868acdee4d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/681175
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

cmd/api: rerun updategolden

Not sure why, but

    go test cmd/api --updategolden

makes changes to the golden files. The changes are just moving things
around, no actual semantic changes. But this is confusing for new
contributors when updating api files.

Change-Id: If27b039f47b94953b7891f8f6b6999ed79953198
Reviewed-on: https://go-review.googlesource.com/c/go/+/675616
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>

runtime: drop NetBSD kernel bug sysmon workaround fixed in NetBSD 9.2

The NetBSD releases supported by the NetBSD project as off today are 9.4
and 10.1. The Go project's NetBSD builders are on 9.3. Thus, it is fine
to drop the workaround which was only needed for NetBSD before 9.2.

Fixes #46495

Cq-Include-Trybots: luci.golang.try:gotip-netbsd-arm64
Change-Id: I3c2ec42fb0f08f7dafdfb7f1dbd97853afc16386
Reviewed-on: https://go-review.googlesource.com/c/go/+/687735
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: clean should respect workspaces

The existing implementation doesn't invoke modload.InitWorkfile during
runClean which in turn causes go clean to ignore workspaces and
consequentially workspace vendoring.

Fixes #74337

Change-Id: I295a1fcc5e81d096971c8cee9c9baa840c7725e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/682856
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>

encoding/json/jsontext: preserve buffer capacity in Decoder.Reset

The Decoder.Reset method is not preserving the internal buffer between
resets, causing buffer capacity to be lost and resulting in unnecessary
allocations when reusing decoders. This is particularly problematic when
decoding many small messages.

This commit fixes the Reset method to preserve the internal buffer. It
makes sure aliasing is removed if the buffer currently points to an
internal byte slice of a bytes.Buffer. It adds a TestDecoderReset test
structured into subtests to better validate the different scenarios.

Change-Id: Ia685bff47034598224489173bb7f2ffd48e89da5
GitHub-Last-Rev: 462ddc936409ee3da6d75def7d9de59eb3c65f8d
GitHub-Pull-Request: golang/go#74120
Reviewed-on: https://go-review.googlesource.com/c/go/+/681177
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>

cmd/go: always return the cached path from go tool -n

If we're running go tool -n always return the cached path of the tool.
We can't always use the cached path when running the tool because if we
copied the tool to the cached location in the same process and then try
to run it we'll run into #22315, producing spurious ETXTBSYs.

Fixes #72824

Change-Id: I81f23773b9028f955ccc97453627ae4f2573814b
Reviewed-on: https://go-review.googlesource.com/c/go/+/688895
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: check TestUsingVDSO ExitError type assertion

Currently this test panics if the error is not an ExitError. We aren't
expecting other errors, but we want to continue to the t.Fatal so the
error contents actually get logged.

For #74672.

Change-Id: I6a6a636cee5ddac500ed7ec549340b02944101ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/689956
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>

doc/next: initialize

Initialize the doc/next directory for the next release by copying the
contents of doc/initial into it.

For #73829.

Change-Id: Ia473d0430043920fc5135844ec6c117eb1b00217
Reviewed-on: https://go-review.googlesource.com/c/go/+/689878
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

internal/goversion: update Version to 1.26

Go 1.26 is in the process of being opened for development (to be
eventually released). This change marks the very beginning of its
development cycle, updating the Version value accordingly.

For #40705.
For #73829.

Change-Id: Ie4ce2d38160dd6283c08e10ecbd7d3a43ed92b48
Reviewed-on: https://go-review.googlesource.com/c/go/+/689877
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/link: scope test to linux & net.sendFile

Limits the scope of new test added in 71c2bf551303930faa32886446910fa5bd0a701a.

Discussion: https://go-review.googlesource.com/c/go/+/684377.

Change-Id: I0e8f513eb564aae277ba8a80ebdad469eb1e6e6a
GitHub-Last-Rev: add2b2e2096e5221ac3d54376c1afa1bec10482c
GitHub-Pull-Request: golang/go#74720
Reviewed-on: https://go-review.googlesource.com/c/go/+/689916
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>

cmd/compile: fix loclist for heap return vars without optimizations

When compiling without optimizations certain variables such as
return params end up missing location lists.

Fixes #65405

Change-Id: Id4ec6b1ab6681fd77b8fefb47a4ec05060c128ef
GitHub-Last-Rev: 5ab6a5398162119dd0cd5325f4239b4559b030bd
GitHub-Pull-Request: golang/go#74398
Reviewed-on: https://go-review.googlesource.com/c/go/+/684377
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>

net: correct comment for ListenConfig.ListenPacket

Fixes #74634

Change-Id: I21196c4aef1b717bfda0b54e61b35e83cfa9dc1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/689075
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

all: go fmt

Change-Id: I6a6a636c341d4ba3518be7f6806093bbdff11c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/689535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/internal/objabi: remove redundant word in comment

Change-Id: I9bbce94a2f36d5de28b946c94652876f01907fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/680115
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sean Liao <sean@liao.dev>

runtime: relax TestMemoryLimitNoGCPercent a bit

It seems to be pretty flaky. I've seen:

retained=289438024
   limit=268435456
   bound=285212672

Which is ~4MB over the bound.

Not sure why this tends to be darwin-specific, but we'll fix
just darwin for now.
(It isn't quite darwin-only, as it appeared in #66893.
But it is certainly worse on darwin.)

Fixes #73136
Update #66893

Change-Id: If609e909bc6c65c2663dd46b7a9bad4fd291c3da
Reviewed-on: https://go-review.googlesource.com/c/go/+/689315
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile: for arm64 epilog, do SP increment with a single instruction

That way, the frame is atomically popped. Previously, for big frames
the SP was unwound in two steps (because arm64 can only add constants
up to 1<<12 in a single instruction).

Fixes #73259

Change-Id: I382c249194ad7bc9fc19607c27487c58d90d49e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/689235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>

runtime: fix asan wrapper for riscv64

Make sure we keep the M in X21. The instruction at line 87
needs to be loading from the M, not from the gsignal.

Fixes #73979, maybe?

Change-Id: I3aba1c35454636138b305bca26e20dbc8e6b1d6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/688975
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/go: check subcommand properties

This change corrects the properties checked by Lookup.  We were
inspecting the properties of the Command receiver; now we are
inspecting the properties of the subcommand.

Fixes #73864.

Change-Id: Ieb462e489fc4f8f0568aa3a2d404b322d627166c
Reviewed-on: https://go-review.googlesource.com/c/go/+/678655
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>

cmd/internal/obj: enable got pcrel itype in fips140 for riscv64

This CL enable R_RISCV_GOT_PCREL_ITYPE in fips140
Fixes #74662

Change-Id: Ic189c4e352517ae74034f207a5f944b610f2eb73
Reviewed-on: https://go-review.googlesource.com/c/go/+/688635
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Julian Zhu <jz531210@gmail.com>

cmd/compile/internal/ssa: restrict architectures for TestDebugLines_74576

CL 687815 recently added TestDebugLines_74576.

The pre-existing debug_lines_test.go file generally restricts the
tested architectures and contains multiple warnings that the
testing approach is useful but fragile, such as:

  "These files must all be short because this is super-fragile."

Despite that, initially I wanted to see what happened on the
different architectures on the trybots in case it might show something
surprising, and I let TestDebugLines_74576 run on all architectures.

That seemed to initially work, but the test is now failing on a
linux/risc64 builder (#74669), so it is likely more prudent to be
more conservative and restrict the platforms like many of the
other pre-existing tests, which is what this CL now does.

Fixes #74669

Change-Id: I9e5a7d3ee901f58253cf72e03c2239df338479e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/688856
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>

os: revert the use of AddCleanup to close files and roots

This reverts commit fdaac84480b02e600660d0ca7c15339138807107.

Updates #70907
Updates #74574
Updates #74642

Reason for revert: Issue #74574

Change-Id: I7b55b85736e4210d9b6f3fd7a24050ac7bdefef9
Reviewed-on: https://go-review.googlesource.com/c/go/+/688435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

go/types: infer correct type for y in append(bytes, y...)

The type-checking logic for append has a special case for
append(bytes, s...) where the typeset for s contains string.
However, this case was triggering even when the typeset contained
only []byte, causing the creation of Signature types of the form
func([]byte, Y) []byte, with the variadic flag set, where Y
is the type of Y (e.g. a type parameter constrained to ~[]byte).
This is an illegal combination: a variadic signature's last
parameter must be a slice, or its typeset must contain string.
This caused x/tools/go/ssa to crash.

This CL narrows the special case to only typesets that contain
string, and adds a test for the inferred signature.
(There's little point in testing that a subsequent NewSignatureType
call would succeed, because the inferred type plainly has
no free type parameters.)

Fixes #73871

Change-Id: Id7641104133371dd6b0077f281cdaa9db84cc1c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/688815
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/compile/internal/escape: improve DWARF .debug_line numbering for literal rewriting optimizations

The literal rewriting optimizations to reduce user allocations
that were implemented in CL 649079 and related CLs like CL 684116
could produce .debug_line tables such that the line numbers
sometimes jumped back to a variable's declaration.

This CL adjusts the positions of the IR nodes to avoid this.

For the first test added here in i74576a.go:

  11  func main() {
  12       a := 1
  13       runtime.Breakpoint()
  14       sink = a
  15  }

Without this fix, the test reports debug lines of 12, 13, 13, 12, 14.
Note it goes backwards from 13 to a second 12.

With this fix, the test reports debug lines of 12, 13, 13, 14
without going backwards.

The test added in i74576b.go creates a slice via make with a
non-constant argument, which similarly shows debug lines going backwards
before this fix but not after. To address the slice make case, we
create a new BasicLit node to then set its position.

There were some related allocation optimizations for struct literals
such as CL 649555 during the Go 1.25 dev cycle, but at least in some
basic test cases, those optimizations did not seem to produce
debug line issues. The struct literal interface conversion test
added in i74576c.go has the same behavior before and after this change.

Finally, running 'go test ./...' in the delve repo root (4a2a6e1aeb)
seems to have many failures with go1.25rc2, but seems to pass with
this CL.

Fixes #74576
Updates #71359

Change-Id: I31faf5fe4bb352fdcd06bdc8606dbdbc4bbd65f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/687815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>

runtime: fix idle time double-counting bug

This change fixes a bug in the accounting of sched.idleTime. In just the
case where the GC CPU limiter needs up-to-date data, sched.idleTime is
incremented in both the P-idle-time and idle-mark-work paths, but it
should only be incremented in the former case.

Fixes #74627.

Change-Id: If41b03da102d47d25bec48ff750a9da27019b71d
Reviewed-on: https://go-review.googlesource.com/c/go/+/687998
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

cmd/compile/internal/escape: speed up analyzing some functions with many closures

Escape analysis examines functions in batches. In some cases, closures
are in the same batch as their parent function, but in other cases,
the closures are in different batches. This can mean the per-batch
ir.ReassignOracle cache is not as effective.

For example, #74615 has 4,000 closures in a single function that
are all in different batches. For that example, these caches
had an ~80% hit rate.

This CL makes the ir.ReassignOracle cache more broadly scoped, instead
of per batch.

This speeds up escape analysis when a function has many closures
that end up in different batches, including this resolves #74615.
For that example, this cache now has a ~100% hit rate.

In addition, in (*batch).rewriteWithLiterals, we also slightly delay
checking the ir.ReassignOracle cache, which is more natural to do now
compared to when rewriteWithLiterals was first merged. This means we can
avoid consulting or populating the cache in more cases. (We also leave
a new type-related TODO there. If we were to also implement that TODO, a
quick test suggests we could independently resolve the specific example
in #74615 even without making the cache more broadly scoped,
though other conceivable examples would not be helped; the scoping of
the cache is the more fundamental improvement.)

If we look at cumulative time spent via pprof for the #74615 example
using this CL, the work of ir.ReassignOracle escape analysis
cache now typically shows zero cpu samples.

This CL passes "go build -toolexec 'toolstash -cmp' -a std cmd".

Fixes #74615

Change-Id: I3c17c527fbb546ffb8a4fa52cd61e41ff3cdb869
Reviewed-on: https://go-review.googlesource.com/c/go/+/688075
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

cmd/link, runtime: on Wasm, put only function index in method table and func table

In the type descriptor's method table, it contains relative PCs of
the methods (relative to the start of the text section) stored as
32-bit offsets. On Wasm, a PC is PC_F<<16 + PC_B, where PC_F is
the function index, and PC_B is the block index. When there are
more than 65536 functions, the PC will not fit into 32-bit (and
relative to the section start doesn't help). Since there are no
more bits for the function index, and the method table always
targets the entry of a method, we put just the PC_F there, and
rewrite back to a full PC at run time when we need the PC. This
way we can have more than 65536 functions.

The func table also contains 32-bit relative PCs, and it also
always points to function entries. Do the same there, as well
as other places where we use relative text offsets.

Also add the relocation type in the relocation overflow error
message.

Also add check for function too big on Wasm. If a function has
more than 65536 blocks, PC_B will overflow and PC = PC_F<<16 + PC_B
will points to the wrong function.

Fixes #64856.

Change-Id: If9c307e9fb1641f367a5f19c39f88f455805d0bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/552835
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: use 32-bit function index on Wasm

Following CL 567896, this is one more place we used only 16 bits
for the function index. Change it to load 32 bits.

For #64856.

Change-Id: I66a78c086e67165604053313751c097a70c50ba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/609118
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

cmd/internal/obj/wasm: use 64-bit instructions for indirect calls

Currently, on Wasm, an indirect call is compiled to

// function index = PC>>16, PC is already on stack
I32WrapI64
I32Const $16
ShrU
// set PC_B to 0
...
// actual call
CallIndirect

Specifically, the function index is extracted from bits 16-31 of
the "PC". When there are more than 65536 functions, this will
overflow and wrap around, causing wrong function being called.

This CL changes it to use 64-bit operations to extract the
function index from the "PC", so there are enough bits to for it.

For #64856.

Change-Id: I83c11db4b78cf66250e88ac02a82bd13730a8914
Reviewed-on: https://go-review.googlesource.com/c/go/+/567896
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

cmd/internal/doc: upgrade godoc pkgsite to 01b046e

Increase the dependency on the doc tool to bring in the fixes to
CL 687918 and CL 687976.

Fixes golang/go#74459

Change-Id: I9cdefdfd9792a142ad14bae3d4f7bb9d8256a246
Reviewed-on: https://go-review.googlesource.com/c/go/+/687997
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>

runtime: use memclrNoHeapPointers to clear inline mark bits

Clearing the inline mark bits with memclrNoHeapPointers is slightly
better than having the compiler insert, e.g. duffzero, since it can take
advantage of wider SIMD instructions. duffzero is likely going away, but
we know things the compiler doesn't, such as the fact that this memory
is nicely aligned. In this particular case, memclrNoHeapPointers does a
better job.

For #73581.

Change-Id: I3918096929acfe6efe6f469fb089ebe04b4acff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/687938
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

runtime: only clear inline mark bits on span alloc if necessary

This change modifies initInlineMarkBits to only clear mark bits if the
span wasn't just freshly allocated from the OS, where we know the bits
are already zeroed. This probably doesn't make a huge difference most of
the time, but it's an easy optimization and helps rule it out as a
source of slowdown.

For #73581.

Change-Id: I78cd4d8968bb0bf6536c0a38ef9397475c39f0ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/687937
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

runtime: have mergeInlineMarkBits also clear the inline mark bits

This is conceptually simpler, as the sweeper doesn't have to worry about
clearing them separately. It also doesn't have a use for them.

This will also be useful to avoiding unnecessary zeroing in
initInlineMarkBits at allocation time. Currently, because it's used in
both span allocation and at sweep time, we cannot blindly trust
needzero.

This change also renames mergeInlineMarkBits to moveInlineMarkBits to
make this change in semantics clearer from the name.

For #73581.

Change-Id: Ib154738a945633b7ff5b2ae27235baa310400139
Reviewed-on: https://go-review.googlesource.com/c/go/+/687936
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

runtime: merge inline mark bits with gcmarkBits 8 bytes at a time

Currently, with Green Tea GC, we need to copy (really bitwise-or) mark
bits back into mspan.gcmarkBits, so that it can propagate to
mspan.allocBits at sweep time. This function does actually seem to make
sweeping small spans a good bit more expensive, though sweeping is still
relatively cheap. There's some low-hanging fruit here though, in that
the merge is performed one byte at a time, but this is pretty
inefficient. We can almost as easily perform this merge one word at a
time instead, which seems to make this operation about 33% faster.

For #73581.

Change-Id: I170d36e7a2193199c423dcd556cba048ebd698af
Reviewed-on: https://go-review.googlesource.com/c/go/+/687935
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

runtime/maps: fix typo in group.go comment (instrinsified -> intrinsified)

Several comments refer to bitset as 'instrinsified', which is likely
a typo, because it refers to the output of the intrinsics implemented
with SIMD.

Change-Id: I00f26b8d8128592ee0e9dc8a1b1480c93a9542d6
GitHub-Last-Rev: 8a4236710979f2f969210e0b261bdb9ae44f3321
GitHub-Pull-Request: golang/go#74624
Reviewed-on: https://go-review.googlesource.com/c/go/+/688016
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>

os: remove useless error check

Change-Id: Ifeb5fecc6e28b79ac03e7dc2ce9531fe5eed3097
GitHub-Last-Rev: 087cf95965920c96befad5adb9e481bdf913d50a
GitHub-Pull-Request: golang/go#66260
Reviewed-on: https://go-review.googlesource.com/c/go/+/570895
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>

runtime: expand GOMAXPROCS documentation

Expand the GOMAXPROCS documentation to include details of how defaults
are selected, as this is something that inquisitive minds will want to
know. I've added an additional warning that these details may changed.

While we are here, add a bit more structure to make it easier to find
the relevant parts of the documentation.

For #73193.

Change-Id: I6a6a636cae93237e3e3174822490d51805e70990
Reviewed-on: https://go-review.googlesource.com/c/go/+/685318
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>

encoding/json: decompose legacy options

WARNING: This commit contains breaking changes
for those already using GOEXPERIMENT=jsonv2.

This decomposes FormatBytesWithLegacySemantics as:
* FormatBytesWithLegacySemantics
* FormatByteArrayAsArray
* ParseBytesWithLooseRFC4648

This decomposes FormatTimeWithLegacySemantics as:
* FormatDurationAsNano
* ParseTimeWithLooseRFC3339

In particular, it splits out specific behaviors from the option
that may need to be specified on a finer-grain level.

FormatByteArrayAsArray and FormatDurationAsNano are targeted
to just the default representation of a [N]byte or time.Duration type.
Both of these are not necessary if the `format` tag is explicitly specified.
However, we want to isolate their behavior from other behaviors that used to
be part of FormatBytesWithLegacySemantics and FormatTimeWithLegacySemantics.

ParseBytesWithLooseRFC4648 and ParseTimeWithLooseRFC3339 are targeted
to just historically buggy parsing according to the relevant RFCs,
which may need to be enabled by some services for backwards compatibility.

While FormatTimeWithLegacySemantics is deleted, we still need
FormatBytesWithLegacySemantics to configure highly esoteric
aspects of how v1 used to handle byte slices.

We rename OmitEmptyWithLegacyDefinition as OmitEmptyWithLegacySemantics
to be consistent with other options with the WithLegacySemantics suffix.

Updates #71497

Change-Id: Ic660515fb086fe3af237135f195736de99c2bd33
Reviewed-on: https://go-review.googlesource.com/c/go/+/685395
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>

encoding/json/v2: add security section to doc

This follows up CL 684315 with an expanded section in the v2 doc.

Updates #14750
Updates #71845

Change-Id: I1ffa97e030f5f2b709e8142028e3c8e0e38b80ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/685195
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

runtime: gofmt after CL 643897 and CL 662455

Change-Id: I3103325ebe29509c00b129a317b5708aece575a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/687715
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>

encoding/json: remove legacy option to EscapeInvalidUTF8

In the presence of invalid UTF-8, the AllowInvalidUTF8 option
allows such bytes to be present, but silently mangles them
using the Unicode replacement character.

The v2 default is to emit the replacement character verbatim
(which is valid UTF-8 and exactly what it is for).

However, the v1 behavior has historically been to emit
the escaped form of the replacement character.
This behavior was introduced in https://go.dev/cl/11211045
where the documentation says that it is:

    replacing invalid bytes with the Unicode replacement rune U+FFFD

but the implementation actually replaces it with
the escaped form of the Unicode replacement rune.
Given that the documentation differs from the implementation,
the actual behavior is likely an oversight.

Given how esoteric of behavior this is,
we change the v1in2 behavior to avoid the unnecesary escaping
and drop support for EscapeInvalidUTF8.

This does not violate the Go compatibility agreement since
we do not document what the exact syntactic output is.
Also, there has already been prior precedence for changing the output:

* [encoding/json: encode \b and \f as '\b' and '\f' in JSON strings](https://go.dev/cl/521675)
* [encoding/json: encode \n in strings as "\n", not "\u000A"](https://go.dev/cl/4678046)
* [encoding/json: encode \t as \t instead of \u0009](https://go.dev/cl/162340043)
* [encoding/json: use standard ES6 formatting for numbers during marshal](https://go.dev/cl/30371)

Fixes #74551

Change-Id: Ib59a873c44713d302f1f6ab103ffba2520d63276
Reviewed-on: https://go-review.googlesource.com/c/go/+/687116
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>

encoding/json/v2: report wrapped io.ErrUnexpectedEOF

In the event that the input is just JSON whitespace,
the underlying jsontext.Decoder treats this as an empty stream
and reports io.EOF.

The logic in unmarshalFull simply casted io.EOF as io.ErrUnexpectedEOF,
which is inconsistent with how all other io.ErrUnexpectedEOF are reported,
which are wrapped within a jsontext.SyntacticError.
Do the same thing for consistency.

We add a v1 test (without goexperiment.jsonv2) to verify that
the behavior is identical to how v1 has always behaved.

We add a v1in2 test (with goexperiment.jsonv2) to verify that
the v1in2 behavior correctly replicates historical v1 behavior.

We also fix a faulty check in v1 Decoder.Decode,
where it tried to detect errUnexpectedEnd and
return an unwrapped io.ErrUnexpectedEOF error.
This is the exact semantic that v1 has always done
in streaming Decoder.Decode (but not non-streaming Unmarshal).
There is a prior bug reported in #25956 about this inconsistency,
but we aim to preserve historical v1 behavior to reduce
the probability of churn when v1 is re-implemented in terms of v2.

Fixes #74548

Change-Id: Ibca52c3699ff3c09141e081c85f853781a86ec8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/687115
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>

crypto/rsa: drop contradictory promise to keep PublicKey modulus secret

We claim to treat N as secret (and indeed bigmod is constant time in
relation to the modulus) but at the same time we warn that all inputs to
VerifyPKCS1v15 and Verify are public:

> The inputs are not considered confidential, and may leak through
> timing side channels, or if an attacker has control of part of the
> inputs.

See #67043 (which focuses on the inverse, recovering signatures by
controlling the public key input to Verify), and in particular
https://github.com/golang/go/issues/67043#issuecomment-2079335804.

Stopping the Verify adaptive attack would require significantly more
complexity, the kind that has caused vulnerabilities in the past (e.g.
CVE-2016-2107). On the other hand, assuming that a public key is
confidential is unlikely to work in practice, since it can be recovered
from just two valid (message, signature) pairs. See for example
https://keymaterial.net/2024/06/15/reconstructing-public-keys-from-signatures/.

This comment was introduced in CL 552935, not really due to a need to
specify that N was secret, but rather to clarify that E is not (so it
could be used in variable-time exponentiation).

Change-Id: I6a6a6964f3f8d2dc2fcc13ce938b271c9de9666b
Reviewed-on: https://go-review.googlesource.com/c/go/+/687616
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>

crypto/rsa: fix documentation formatting

Change-Id: I6a6a696422f9ab73b9ddee131b17d3c177fefc4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/687615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

runtime: turn off large memmove tests under asan/msan

Just like we do for race mode. They are just too slow when running
with the sanitizers.

Fixes #59448

Change-Id: I86e3e3488ec5c4c29e410955e9dc4cbc99d39b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/687535
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Keith Randall <khr@golang.org>

cmd/link: do size fixups after symbol references are loaded

When we do a size fixup, we need to clone the symbol to an
external symbol so we can modify it. This includes cloning the
relocations, which includes resolving the relocations. If the
symbol being fixed has a relocation referencing a non-Go symbol,
that symbol has not yet been created, it will be resolved to an
empty symbol. Load the references first, so the referenced symbol,
even if it is a non-Go symbol, exists.

Fixes #74537.

Change-Id: I81525bd7c3e232b80eefeb0f18e13ba5331e1510
Reviewed-on: https://go-review.googlesource.com/c/go/+/687315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

os: trivial comment fix

"Geese" here looks like an autocorrect-o of "oses", I think writing it out
makes more sense.

Change-Id: Iba89a6c0b94657e2e93937cc153f07aea1d04e04
GitHub-Last-Rev: 4f3a780f327d6c807e9b154d781ee69a10d391e4
GitHub-Pull-Request: golang/go#74332
Reviewed-on: https://go-review.googlesource.com/c/go/+/682776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

synctest: fix comments for time.Now() in synctests

Also add a test case to make sure that time.Now() results in the
documented date.

Change-Id: Ic4cc577eba485b7c6e1a64122da06d7075bbe12e
Reviewed-on: https://go-review.googlesource.com/c/go/+/685677
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Christian Höppner <hoeppi@google.com>
Reviewed-by: Damien Neil <dneil@google.com>

crypto/cipher: Fix comment punctuation

Change-Id: I7dc086a87d28ab847288eed13f719421420cd004
Reviewed-on: https://go-review.googlesource.com/c/go/+/686997
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

runtime: run TestSignalDuringExec in its own process group

TestSignalDuringExec sends a SIGWINCH to the whole process group.
However, it may execute concurrently with other copies of the runtime
tests, especially through `go tool dist`, and gdb version <12.1 has a
bug in non-interactive mode where recieving a SIGWINCH causes a crash.

This change modifies SignalDuringExec in the testprog to first fork
itself into a new process group. To avoid issues with Ctrl+C and the new
process group hanging, the new process blocks on a pipe that is passed
down to it. This pipe is automatically closed when its parent exits,
which should ensure that the subprocess also exits.

Fixes #58932.

Change-Id: I3906afa28cf8b15d22ae612d071bce7f30fc3e6c
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-noswissmap,gotip-linux-amd64-longtest-aliastypeparams,gotip-linux-amd64-longtest,gotip-linux-386-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/686875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

crypto/tls: empty server_name conf. ext. from server

When a TLS server uses the information from the server_name extension in
a client hello, and the connection isn't resuming, it should return an
empty server_name extension in its server hello (or encrypted extensions
for TLS 1.3).

For TLS <1.3 we we do this in doFullHandshake(), by setting the
pre-existing serverHelloMsg.serverNameAck bool. We know that the
connection isn't resuming based on the context where this function is
called.

For TLS 1.3, a new encryptedExtensionsMsg.serverNameAck bool is added,
and populated as appropriate in sendServerParameters() based on whether
the conn was resumed or not. The encryptedExtensionsMsg marshalling is
updated to emit the encrypted extension based on that field.

These changes allow enabling the ServerNameExtensionServer-* bogo tests
that verify both the presence and absence of the server_name extension
based on the relevant specifications.

Resolves #74282
Updates #72006

Change-Id: I703bc2ec916b50906bdece7b7483a7faed7aa8e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/684795
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>

cmd/go: disable support for multiple vcs in one module

Removes the somewhat redundant vcs.FromDir, "allowNesting" argument,
which was always enabled, and disallow multiple VCS metadata folders
being present in a single directory. This makes VCS injection attacks
much more difficult.

Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior.

Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue.

Fixes #74380
Fixes CVE-2025-4674

Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789
Reviewed-on: https://go-review.googlesource.com/c/go/+/686515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Commit-Queue: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>

internal: make struct comment match struct name

Change-Id: I85a4051bd3413bd843b17d22cf9120f615cfe8db
Reviewed-on: https://go-review.googlesource.com/c/go/+/686295
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>

cmd/compile: document that nosplit directive is unsafe

For #74478

Change-Id: I902e9a92cdacb5ad6dafa9896640f8196ba1d56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/686115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>

cmd/compile: run fmt on ssa

prove.go used to make my editor and precomit checks very unhappy.

Change-Id: I25f7ffa2191480bc1b4f91fa91ccf3e4768045fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/685818
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

internal/trace: only test for sync preemption if async preemption is off

Currently, the test change made for the fix to #68090 is flaky. This is
because the sync-point-only goroutine that we expect to be sync
preempted might only ever get async preempted in some circumstances.

This change adds a variant to all trace tests to run with
asyncpreemptoff=1, and the stacks test, the flaky one, only actually
checks for the sync-point in the trace when async preemption is
disabled.

Fixes #74417.

Change-Id: Ib6341bbc26921574b8f0fff6dd521ce83f85499c
Reviewed-on: https://go-review.googlesource.com/c/go/+/686055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>