-
Notifications
You must be signed in to change notification settings - Fork 17.9k
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: golang/go
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: go1.17.12
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: golang/go
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: go1.17.13
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 6 commits
- 12 files changed
- 5 contributors
Commits on Jul 22, 2022
-
[release-branch.go1.17] runtime: use saved LR when unwinding through …
…morestack On LR machine, consider F calling G calling H, which grows stack. The stack looks like ... G's frame: ... locals ... saved LR = return PC in F <- SP points here at morestack H's frame (to be created) At morestack, we save gp.sched.pc = H's morestack call gp.sched.sp = H's entry SP (the arrow above) gp.sched.lr = return PC in G Currently, when unwinding through morestack (if _TraceJumpStack is set), we switch PC and SP but not LR. We then have frame.pc = H's morestack call frame.sp = H's entry SP (the arrow above) As LR is not set, we load it from stack at *sp, so frame.lr = return PC in F As the SP hasn't decremented at the morestack call, frame.fp = frame.sp = H's entry SP Unwinding a frame, we have frame.pc = old frame.lr = return PC in F frame.sp = old frame.fp = H's entry SP a.k.a. G's SP The PC and SP don't match. The unwinding will go off if F and G have different frame sizes. Fix this by preserving the LR when switching stack. Also add code to detect infinite loop in unwinding. TODO: add some test. I can reproduce the infinite loop (or throw with added check) but the frequency is low. Fixes #53111. Updates #52116. Change-Id: I6e1294f1c6e55f664c962767a1cf6c466a0c0eff Reviewed-on: https://go-review.googlesource.com/c/go/+/400575 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Eric Fang <eric.fang@arm.com> Reviewed-by: Benny Siegert <bsiegert@gmail.com> (cherry picked from commit 74f0009) Reviewed-on: https://go-review.googlesource.com/c/go/+/408822 Reviewed-by: Austin Clements <austin@google.com>
Configuration menu - View commit details
-
Copy full SHA for c25b12f - Browse repository at this point
Copy the full SHA c25b12fView commit details
Commits on Jul 25, 2022
-
[release-branch.go1.17] runtime: clear timerModifiedEarliest when las…
…t timer is deleted timerModifiedEarliest contains the lowest possible expiration for a modified earlier timer, which may be earlier than timer0When because we haven't yet updated the heap. Note "may", as the modified earlier timer that set timerModifiedEarliest may have since been modified later or deleted. We can clear timerModifiedEarliest when the last timer is deleted because by definition there must not be any modified earlier timers. Why does this matter? checkTimersNoP claims that there is work to do if timerModifiedEarliest has passed, causing findRunnable to loop back around to checkTimers. But the code to clean up timerModifiedEarliest in checkTimers (i.e., the call to adjusttimers) is conditional behind a check that len(pp.timers) > 0. Without clearing timerModifiedEarliest, a spinning M that would otherwise go to sleep will busy loop in findRunnable until some other work is available. Note that changing the condition on the call to adjusttimers would also be a valid fix. I took this approach because it feels a bit cleaner to clean up timerModifiedEarliest as soon as it is known to be irrelevant. For #51654. Fixes #53846. Change-Id: I3f3787c67781cac7ce87939c5706cef8db927dd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/417434 Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit c006b7a) Reviewed-on: https://go-review.googlesource.com/c/go/+/417476
Configuration menu - View commit details
-
Copy full SHA for 66c60f0 - Browse repository at this point
Copy the full SHA 66c60f0View commit details -
[release-branch.go1.17] cmd/compile: fix prove pass when upper condit…
…ion is <= maxint When the terminating condition is <= X, we need to make sure that X+step doesn't overflow. Fixes #53617 Change-Id: I36e5384d05b4d7168e48db6094200fcae409bfe5 Reviewed-on: https://go-review.googlesource.com/c/go/+/415219 Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> (cherry picked from commit 31b8c23) Reviewed-on: https://go-review.googlesource.com/c/go/+/415415 Reviewed-by: Keith Randall <khr@google.com>
Configuration menu - View commit details
-
Copy full SHA for 489c148 - Browse repository at this point
Copy the full SHA 489c148View commit details
Commits on Jul 26, 2022
-
[release-branch.go1.17] cmd/compile: do not use special literal assig…
…nment if LHS is address-taken A composite literal assignment x = T{field: v} may be compiled to x = T{} x.field = v We already do not use this form is RHS uses LHS. If LHS is address-taken, RHS may uses LHS implicitly, e.g. v = &x.field x = T{field: *v} The lowering above would change the value of RHS (*v). Updates #52953. Fixes #52960. Change-Id: I3f798e00598aaa550b8c17182c7472fef440d483 Reviewed-on: https://go-review.googlesource.com/c/go/+/407014 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 1c77137) Reviewed-on: https://go-review.googlesource.com/c/go/+/419451 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Configuration menu - View commit details
-
Copy full SHA for d9242f7 - Browse repository at this point
Copy the full SHA d9242f7View commit details
Commits on Jul 29, 2022
-
[release-branch.go1.17] math/big: check buffer lengths in GobDecode
In Float.GobDecode and Rat.GobDecode, check buffer sizes before indexing slices. Updates #53871 Fixes #54094 Change-Id: I1b652c32c2bc7a0e8aa7620f7be9b2740c568b0a Reviewed-on: https://go-review.googlesource.com/c/go/+/417774 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tatiana Bradley <tatiana@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> (cherry picked from commit 055113e) Reviewed-on: https://go-review.googlesource.com/c/go/+/419814 Reviewed-by: Julie Qiu <julieqiu@google.com>
Configuration menu - View commit details
-
Copy full SHA for 703c8ab - Browse repository at this point
Copy the full SHA 703c8abView commit details
Commits on Aug 1, 2022
-
[release-branch.go1.17] go1.17.13
Change-Id: Id21203787dc0bbca2548044d7bcc442204dfdd7d Reviewed-on: https://go-review.googlesource.com/c/go/+/420554 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
Configuration menu - View commit details
-
Copy full SHA for 15da892 - Browse repository at this point
Copy the full SHA 15da892View commit details
There are no files selected for viewing