debug/buildinfo: fix buildinfo data section location on elf and pe #53073
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CL 404296 breaks the PPC64LE build because the .TOC. symbol is visibility hidden and was skipped from the "unresolved symbol" check (the check needs to be fix). In face, the .TOC. symbol is special in that it doesn't have a type but we have special logic to assign a value to it in the address pass. So we can actually resolve a relocation to .TOC.. We already have a special case for PIE. It also applies to non-PIE as well. Fix PPC64LE builds. Change-Id: Iaf7e36f10c4d0a40fc56b2135e5ff38815e203b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/404302 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Noder pass will build a closure to implement generic function instantiation which may produce `.dict` and `.rcvr` ident. Since we allow `.dict` during exporting, we should allow `.rcvr` too. Fixes #52241. Change-Id: Ifc3912ba5155b5ac1887f20830da64f4fb3fceb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/404314 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
`go mod tidy` results in panic due to nil pointer dereference with the current implementation. Though the panic occurs only in a limited situation described as below, we had better fix it. Situation: - go.mod is in the exactly system's temporary directory (i.e. temp root) - `go mod tidy` in temp root or in the child directory not having go.mod No go.mod are found in the situation (i.e. *modFile is nil), however, *modFile is referred without nil check. Although just adding nil check works well, the better solution is using ModFile() function. It works as same as the current implementation and, in addition, it has either nil check and user friendly error indication. With using it, users can get a proper error message like "go.mod file not found in current directory or any parent directory" instead of a panic. Fixes #51992 Change-Id: I2ba26762778acca6cd637c8eb8c615fb747063f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/400554 Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: David Chase <drchase@google.com>
This provides clearer synchronization invariants: if it occurs at all, the call to c.Process.Kill always occurs before Wait returns. It also allows any unexpected errors from the goroutine to be propagated back to Wait. For #50436. Change-Id: I7ddadc73e6e67399596e35393f5845646f6111ab Reviewed-on: https://go-review.googlesource.com/c/go/+/401896 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the file net/dnsclient_unix.go in the function newRequest error handling is missing after calling b.Finish(). If the implementation of dnsmessage.Builder.Finish changes it is theoretically possible that the missing error handling introduces a nil pointer exception. Fixes #50946 Change-Id: I3f0785f71def6649d6089d0af71c9e50f5ccb259 GitHub-Last-Rev: 2a2197f GitHub-Pull-Request: #50948 Reviewed-on: https://go-review.googlesource.com/c/go/+/381966 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
This does not enable GCM or CBC variants for ppc64, they require more work to support bi-endian. Updates #18499 Change-Id: Ic2bbe81c60107abc0a4803d8b9a833213286b1d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/404395 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Paul Murphy <murp@ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Filippo Valsorda <valsorda@google.com>
Fixes #52774 Change-Id: I853f462146d10e44a35e5a8716d41f32b6052fd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/404936 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com>
The assignment operation in the program seems to be redundant, the first judgment will continue to overwrite the previous value. The subsequent slicing operation will cut all the values without frequency. Change-Id: Id59fc36dd5bacfde881edaf0d9c1af5348286611 Reviewed-on: https://go-review.googlesource.com/c/go/+/244157 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Joe Tsai <joetsai@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
This CL updates big.Jacobi to avoid forcing its y argument to escape to the heap. The argument was escaping because it was being passed through an empty interface to fmt.Sprintf during an assertion failure. As a result, callers of Jacobi and Int.ModSqrt (which calls Jacobi) could not keep this value on the stack. Noticed when working on cockroachdb/apd#103. Change-Id: I5db9ee2149bf13b921886929425861721b53b085 GitHub-Last-Rev: 3ee07b5 GitHub-Pull-Request: #50527 Reviewed-on: https://go-review.googlesource.com/c/go/+/377014 Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
When calling a C function, line information will be incorrect if the function call's closing parenthesis is not on the same line as the last argument. We add a comment with the line info for the return statement to guide debuggers to the correct line. Fixes #49839. Change-Id: I8bc2ce35fec9cbcafbbe8536d5a79dc487eb24bb GitHub-Last-Rev: 8b28646 GitHub-Pull-Request: #49840 Reviewed-on: https://go-review.googlesource.com/c/go/+/367454 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
When using windows some users got a weird error (File not found) when the timezone database is not found. It happens because some methods in the time package don't treat ERROR_PATH_NOT_FOUND and ENOTDIR. To solve it was added a conversion to ENOTENT error. Fixes #50248 Change-Id: I11c84cf409e01eafb932aea43c7293c8218259b8 GitHub-Last-Rev: fe7fff9 GitHub-Pull-Request: #50906 Reviewed-on: https://go-review.googlesource.com/c/go/+/381957 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
When the procUnpin is placed after shared.pushHead, there is no need for x as a flag to indicate the previous process. This CL can make the logic clear, and at the same time reduce a redundant judgment. Change-Id: I34ec9ba4cb5b5dbdf13a8f158b90481fed248cf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/360059 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
A Java jar file is a zip file, but it can have a prefix that is a bash script that unpacks the zip file. Most zip programs ignore such prefixes. This CL changes the archive/zip package to do the same. Fixes #10464 Fixes #51337 Change-Id: I976e9c64684644317bd21077bc5b4a2baf626ee6 Reviewed-on: https://go-review.googlesource.com/c/go/+/387976 Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Ian Lance Taylor <iant@google.com>
Make some code more simple. Change-Id: I801adf0dba5f6c515681345c732dbb907f945419 GitHub-Last-Rev: a505146 GitHub-Pull-Request: #49626 Reviewed-on: https://go-review.googlesource.com/c/go/+/364634 Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Change-Id: I655095874a90fc3e390df5609e68f0e48a042fea GitHub-Last-Rev: 6d3199b GitHub-Pull-Request: #52759 Reviewed-on: https://go-review.googlesource.com/c/go/+/404814 Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com>
An invalid program may produce invalid types. If the program calls unsafe.Sizeof on such a type, which is a compile-time computation, the size-computation must be able to handle it. Add the invalid type to the list of permissible basic types and give it a size of 1 (word). Fixes #52748. Change-Id: I6c409628f9b77044758caf71cdcb199f9e77adea Reviewed-on: https://go-review.googlesource.com/c/go/+/404894 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
For this code: z &= 63 _ = x<<z | x>>(64-z) Now can prove 'x<<z' in bound. In ppc64 lowering pass, it will not produce an extra '(ANDconst <typ.Int64> [63] z)' causing codegen/rotate.go failed. Just remove the type check in rewrite rules as the workaround. Removes 32 bounds checks during make.bat. Fixes #52563. Change-Id: I14ed2c093ff5638dfea7de9bc7649c0f756dd71a Reviewed-on: https://go-review.googlesource.com/c/go/+/404315 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Keith Randall <khr@golang.org> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org>
This results in a 1.7-2.4x improvement in native go crypto/elliptic multiplication operations on PPC64, and similar improvements might be possible on other architectures which use flags or similar to represent the carry bit in SSA form. If it is possible, schedule carry chains independently of each other to avoid clobbering the carry flag. This is very expensive. This is done by: 1. Identifying carry bit using, but not creating ops, and lowering their priority below all other ops which do not need to be placed at the top of a block. This effectively ensures only one carry chain will be placed at a time in most important cases (crypto/elliptic/internal/fiat contains most of them). 2. Raising the priority of carry bit generating ops to schedule later in a block to ensure they are placed as soon as they are ready. Likewise, tuple ops which separate carrying ops are scored similar to 2 above. This prevents unrelated ops from being scheduled between carry-dependent operations. This occurs when unrelated ops are ready to schedule alongside such tuple ops. This reduces the chances a flag clobbering op might be placed between two carry-dependent operations. With PPC64 Add64/Sub64 lowering into SSA and this patch, the net performance difference in crypto/elliptic benchmarks on P9/ppc64le are: name old time/op new time/op delta ScalarBaseMult/P256 46.3µs ± 0% 46.9µs ± 0% +1.34% ScalarBaseMult/P224 356µs ± 0% 209µs ± 0% -41.14% ScalarBaseMult/P384 1.20ms ± 0% 0.57ms ± 0% -52.14% ScalarBaseMult/P521 3.38ms ± 0% 1.44ms ± 0% -57.27% ScalarMult/P256 199µs ± 0% 199µs ± 0% -0.17% ScalarMult/P224 357µs ± 0% 212µs ± 0% -40.56% ScalarMult/P384 1.20ms ± 0% 0.58ms ± 0% -51.86% ScalarMult/P521 3.37ms ± 0% 1.44ms ± 0% -57.32% MarshalUnmarshal/P256/Uncompressed 2.59µs ± 0% 2.52µs ± 0% -2.63% MarshalUnmarshal/P256/Compressed 2.58µs ± 0% 2.52µs ± 0% -2.06% MarshalUnmarshal/P224/Uncompressed 1.54µs ± 0% 1.40µs ± 0% -9.42% MarshalUnmarshal/P224/Compressed 1.54µs ± 0% 1.39µs ± 0% -9.87% MarshalUnmarshal/P384/Uncompressed 2.40µs ± 0% 1.80µs ± 0% -24.93% MarshalUnmarshal/P384/Compressed 2.35µs ± 0% 1.81µs ± 0% -23.03% MarshalUnmarshal/P521/Uncompressed 3.79µs ± 0% 2.58µs ± 0% -31.81% MarshalUnmarshal/P521/Compressed 3.80µs ± 0% 2.60µs ± 0% -31.67% Note, P256 uses an asm implementation, thus, little variation is expected. Updates #40171 Change-Id: I810850e8ff429505424c92d6fe37f99aaa0c6e84 Reviewed-on: https://go-review.googlesource.com/c/go/+/393656 Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Filippo Valsorda <valsorda@google.com>
Optimized index2to16 loop by unrolling the loop by 4. Multiple benchmark tests show performance improvement on POWER9. Similar improvements are seen on POWER10. Added tests to ensure changes work fine. name old time/op new time/op delta Index/10 18.3ns ± 0% 19.7ns ±25% ~ Index/32 75.3ns ± 0% 69.2ns ± 0% -8.22% Index/4K 5.53µs ± 0% 3.69µs ± 0% -33.20% Index/4M 5.64ms ± 0% 3.75ms ± 0% -33.55% Index/64M 92.9ms ± 0% 61.6ms ± 0% -33.69% IndexHard2 1.41ms ± 0% 0.93ms ± 0% -33.75% CountHard2 1.41ms ± 0% 0.93ms ± 0% -33.75% Change-Id: If9331df6a141a4716724b8cb648d2b91bdf17e5f Reviewed-on: https://go-review.googlesource.com/c/go/+/377016 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Fix up a test to insure that it does the right thing when "go test -cover" is in effect. Fixes #52761. Change-Id: I0c141181e2dcaefd592fb04813f812f2800511da Reviewed-on: https://go-review.googlesource.com/c/go/+/404715 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Plan 9 doesn't have symbolic links, so EvalSymlinks can be simplified just to check validity of the path and call Clean. This saves a lot of redundant file system activity. Updates #50775 Change-Id: I84c24ef1d5e6e38fd19df2d37c72fbf883f0140d Reviewed-on: https://go-review.googlesource.com/c/go/+/404954 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by: David du Colombier <0intro@gmail.com>
This CL we turn regabi on by default. Later CLs will clean up fallback code. name old time/op new time/op delta BinaryTree17 35.2s ± 2% 31.0s ± 1% -11.87% (p=0.008 n=5+5) Fannkuch11 10.8s ± 1% 11.0s ± 1% +1.73% (p=0.008 n=5+5) FmtFprintfEmpty 379ns ± 2% 389ns ± 4% ~ (p=0.095 n=5+5) FmtFprintfString 746ns ± 5% 693ns ± 2% -7.10% (p=0.008 n=5+5) FmtFprintfInt 769ns ± 3% 744ns ± 2% -3.23% (p=0.032 n=5+5) FmtFprintfIntInt 1.14µs ± 3% 1.09µs ± 4% -4.51% (p=0.032 n=5+5) FmtFprintfPrefixedInt 5.04µs ± 0% 4.53µs ± 1% -10.14% (p=0.008 n=5+5) FmtFprintfFloat 1.82µs ± 4% 1.67µs ± 4% -8.12% (p=0.008 n=5+5) FmtManyArgs 3.92µs ± 3% 3.67µs ± 2% -6.20% (p=0.008 n=5+5) GobDecode 137ms ± 1% 132ms ± 1% -4.13% (p=0.008 n=5+5) GobEncode 93.9ms ± 1% 89.3ms ± 2% -4.84% (p=0.008 n=5+5) Gzip 2.54s ± 1% 2.59s ± 1% +1.95% (p=0.008 n=5+5) Gunzip 1.39s ± 1% 1.35s ± 0% -3.07% (p=0.008 n=5+5) HTTPClientServer 416µs ± 1% 397µs ± 0% -4.39% (p=0.016 n=5+4) JSONEncode 202ms ± 1% 196ms ± 2% -2.76% (p=0.008 n=5+5) JSONDecode 478ms ± 2% 435ms ± 4% -8.97% (p=0.008 n=5+5) Mandelbrot200 44.1ms ± 0% 44.1ms ± 0% ~ (p=0.151 n=5+5) GoParse 33.7ms ± 1% 31.5ms ± 1% -6.55% (p=0.008 n=5+5) RegexpMatchEasy0_32 624ns ± 6% 548ns ± 6% -12.08% (p=0.008 n=5+5) RegexpMatchEasy0_1K 4.49µs ± 1% 3.59µs ± 1% -20.21% (p=0.008 n=5+5) RegexpMatchEasy1_32 654ns ± 4% 556ns ± 2% -15.01% (p=0.008 n=5+5) RegexpMatchEasy1_1K 6.21µs ± 2% 4.96µs ± 3% -20.22% (p=0.008 n=5+5) RegexpMatchMedium_32 9.78µs ± 5% 8.03µs ± 4% -17.96% (p=0.008 n=5+5) RegexpMatchMedium_1K 280µs ± 4% 223µs ± 5% -20.42% (p=0.008 n=5+5) RegexpMatchHard_32 17.0µs ± 3% 15.2µs ± 3% -10.63% (p=0.008 n=5+5) RegexpMatchHard_1K 520µs ± 4% 485µs ± 6% -6.76% (p=0.008 n=5+5) Revcomp 35.2s ± 1% 35.2s ± 1% ~ (p=0.690 n=5+5) Template 686ms ± 2% 610ms ± 3% -11.09% (p=0.008 n=5+5) TimeParse 1.91µs ± 2% 1.78µs ± 1% -6.86% (p=0.008 n=5+5) TimeFormat 3.04µs ± 2% 2.84µs ± 3% -6.71% (p=0.008 n=5+5) name old speed new speed delta GobDecode 5.59MB/s ± 1% 5.84MB/s ± 1% +4.40% (p=0.008 n=5+5) GobEncode 8.17MB/s ± 1% 8.59MB/s ± 3% +5.14% (p=0.008 n=5+5) Gzip 7.65MB/s ± 1% 7.50MB/s ± 1% -1.96% (p=0.008 n=5+5) Gunzip 13.9MB/s ± 1% 14.4MB/s ± 0% +3.16% (p=0.008 n=5+5) JSONEncode 9.63MB/s ± 1% 9.90MB/s ± 2% +2.83% (p=0.008 n=5+5) JSONDecode 4.06MB/s ± 2% 4.46MB/s ± 4% +9.90% (p=0.008 n=5+5) GoParse 1.72MB/s ± 1% 1.84MB/s ± 1% +6.85% (p=0.008 n=5+5) RegexpMatchEasy0_32 51.4MB/s ± 6% 58.4MB/s ± 6% +13.72% (p=0.008 n=5+5) RegexpMatchEasy0_1K 228MB/s ± 1% 286MB/s ± 1% +25.32% (p=0.008 n=5+5) RegexpMatchEasy1_32 48.9MB/s ± 4% 57.5MB/s ± 2% +17.63% (p=0.008 n=5+5) RegexpMatchEasy1_1K 165MB/s ± 2% 207MB/s ± 3% +25.37% (p=0.008 n=5+5) RegexpMatchMedium_32 3.27MB/s ± 5% 3.99MB/s ± 5% +21.87% (p=0.008 n=5+5) RegexpMatchMedium_1K 3.66MB/s ± 4% 4.60MB/s ± 5% +25.61% (p=0.008 n=5+5) RegexpMatchHard_32 1.88MB/s ± 3% 2.10MB/s ± 3% +12.03% (p=0.008 n=5+5) RegexpMatchHard_1K 1.97MB/s ± 4% 2.11MB/s ± 6% +7.31% (p=0.008 n=5+5) Revcomp 7.23MB/s ± 1% 7.23MB/s ± 1% ~ (p=0.810 n=5+5) Template 2.83MB/s ± 2% 3.18MB/s ± 4% +12.52% (p=0.008 n=5+5) Change-Id: Ie02aa5ebe60607dbb5007da0efae731c36e96399 Reviewed-on: https://go-review.googlesource.com/c/go/+/402374 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: mzh <mzh@golangcn.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
On ARM64, an If block is lowered to (NZ cond yes no). This is incorrect because cond is a boolean value and therefore only the last byte is meaningful (same as AMD64, see ARM64Ops.go). But here we are comparing a full register width with 0. Correct it by comparing only the last bit. Fixes #52788. Change-Id: I2cacf9f3d2f45e149c361a290f511b2d4ed845c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/405114 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com>
CL 266638 marked racewriterange (and some other race functions) as ABIinternal but missed racereadrange. arm64 and ppc64le (the other two register ABI platforms at the moment) already have racereadrange marked as such. The other two instrumented calls are to racefuncenter/racefuncexit. Do you think they would need this treatment as well? arm64 already does, but amd64 and ppc64le do not. Fixes #51459 Change-Id: I3f54e1298433b6d67bfe18120d9f86205ff66a73 Reviewed-on: https://go-review.googlesource.com/c/go/+/393154 Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Following CL 405114, the extension rule is also wrong. It is safe to drop the extension if the value is from a boolean-generating instruction, but not a boolean-typed Value in general (e.g. a Phi or a in-register parameter). Fix it. Updates #52788. Change-Id: Icf3028fe8e90806f9f57fbe2b38d47da27a97e2a Reviewed-on: https://go-review.googlesource.com/c/go/+/405115 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Since when CL 29244 did remove it. Change-Id: I5f96d7404209cbc336b0541502943871461cb72e Reviewed-on: https://go-review.googlesource.com/c/go/+/403714 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org>
This patch adds support for REP STOSB in memclr(). The current implementation uses REP STOSB when 1) ERMS is supported 2) size is bigger than 2kb and less than 32mb. The threshold of 2kb is chosen based on benchmark results and is close to what Intel mentioned in their comparison of ERMSB and AVX (Table 3-4. Relative Performance of Memcpy() Using ERMSB Vs. 128-bit AVX in the Intel Optimization Guide). While REP STOS uses a no-RFO write protocol, ERMS could show the same or slower performance comparing to Non-Temporal Stores when the size is bigger than LLC depending on hardware. Benchmarks (including MemclrRange from CL373362) goos: darwin goarch: amd64 pkg: runtime cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz name old time/op new time/op delta Memclr/5-12 1.90ns ± 2% 2.13ns ± 2% +11.72% (p=0.001 n=7+7) Memclr/16-12 2.33ns ± 4% 2.36ns ± 4% ~ (p=0.259 n=7+7) Memclr/64-12 2.58ns ± 2% 2.61ns ± 3% ~ (p=0.091 n=7+7) Memclr/256-12 4.89ns ± 4% 4.94ns ± 3% ~ (p=0.620 n=7+7) Memclr/4096-12 38.4ns ± 2% 39.5ns ± 5% ~ (p=0.078 n=7+7) Memclr/65536-12 929ns ± 2% 1040ns ±19% ~ (p=0.268 n=5+7) Memclr/1M-12 24.2µs ± 5% 19.0µs ± 9% -21.62% (p=0.001 n=7+7) Memclr/4M-12 93.3µs ± 3% 73.2µs ± 4% -21.50% (p=0.001 n=7+7) Memclr/8M-12 209µs ± 6% 164µs ± 3% -21.55% (p=0.001 n=7+7) Memclr/16M-12 731µs ± 4% 507µs ± 6% -30.71% (p=0.001 n=7+7) Memclr/64M-12 1.79ms ± 1% 1.83ms ± 3% +2.47% (p=0.041 n=6+6) MemclrRange/1_2_47K-12 873ns ± 3% 899ns ± 5% ~ (p=0.053 n=7+7) MemclrRange/2_8_166K-12 2.98µs ± 4% 2.90µs ± 5% ~ (p=0.165 n=7+7) MemclrRange/4_16_315K-12 6.81µs ± 4% 5.31µs ± 9% -22.01% (p=0.001 n=7+7) MemclrRange/128_256_1623K-12 37.5µs ± 4% 28.1µs ± 4% -25.19% (p=0.001 n=7+6) [Geo mean] 1.56µs 1.43µs -8.43% name old speed new speed delta Memclr/5-12 2.63GB/s ± 2% 2.35GB/s ± 2% -10.50% (p=0.001 n=7+7) Memclr/16-12 6.86GB/s ± 4% 6.79GB/s ± 4% ~ (p=0.259 n=7+7) Memclr/64-12 24.8GB/s ± 2% 24.5GB/s ± 3% ~ (p=0.097 n=7+7) Memclr/256-12 52.4GB/s ± 4% 51.9GB/s ± 3% ~ (p=0.620 n=7+7) Memclr/4096-12 107GB/s ± 2% 104GB/s ± 5% ~ (p=0.073 n=7+7) Memclr/65536-12 70.6GB/s ± 2% 64.2GB/s ±21% ~ (p=0.268 n=5+7) Memclr/1M-12 43.4GB/s ± 5% 55.5GB/s ±10% +28.04% (p=0.001 n=7+7) Memclr/4M-12 45.0GB/s ± 4% 57.3GB/s ± 4% +27.38% (p=0.001 n=7+7) Memclr/8M-12 40.1GB/s ± 5% 51.1GB/s ± 3% +27.37% (p=0.001 n=7+7) Memclr/16M-12 23.0GB/s ± 4% 33.1GB/s ± 6% +44.39% (p=0.001 n=7+7) Memclr/64M-12 37.6GB/s ± 1% 36.7GB/s ± 3% -2.38% (p=0.041 n=6+6) MemclrRange/1_2_47K-12 55.9GB/s ± 3% 54.3GB/s ± 5% ~ (p=0.053 n=7+7) MemclrRange/2_8_166K-12 57.4GB/s ± 5% 58.9GB/s ± 5% ~ (p=0.165 n=7+7) MemclrRange/4_16_315K-12 47.4GB/s ± 4% 60.9GB/s ± 9% +28.40% (p=0.001 n=7+7) MemclrRange/128_256_1623K-12 44.3GB/s ± 4% 58.4GB/s ± 9% +31.73% (p=0.001 n=7+7) [Geo mean] 33.6GB/s 36.8GB/s +9.27% goos: linux goarch: amd64 pkg: runtime cpu: Intel(R) Xeon(R) Gold 6230N CPU @ 2.30GHz name old time/op new time/op delta Memclr/5-2 2.53ns ± 0% 2.52ns ± 0% -0.25% (p=0.001 n=7+7) Memclr/16-2 2.77ns ± 0% 2.55ns ± 0% -7.97% (p=0.000 n=5+7) Memclr/64-2 3.16ns ± 0% 3.16ns ± 0% ~ (p=0.432 n=7+7) Memclr/256-2 7.26ns ± 0% 7.26ns ± 0% ~ (p=0.220 n=7+7) Memclr/4096-2 49.3ns ± 0% 43.5ns ± 0% -11.80% (p=0.001 n=7+7) Memclr/65536-2 1.32µs ± 1% 1.24µs ± 0% -6.31% (p=0.001 n=7+7) Memclr/1M-2 27.3µs ± 0% 26.6µs ± 5% ~ (p=0.195 n=7+7) Memclr/4M-2 195µs ± 0% 148µs ± 4% -24.22% (p=0.001 n=7+7) Memclr/8M-2 391µs ± 0% 308µs ± 0% -21.09% (p=0.001 n=7+6) Memclr/16M-2 782µs ± 0% 639µs ± 1% -18.31% (p=0.001 n=7+7) Memclr/64M-2 2.83ms ± 1% 2.84ms ± 1% ~ (p=0.620 n=7+7) MemclrRange/1K_2K-2 1.24µs ± 0% 1.24µs ± 0% ~ (p=1.000 n=7+6) MemclrRange/2K_8K-2 3.89µs ± 0% 3.11µs ± 0% -20.00% (p=0.001 n=6+7) MemclrRange/4K_16K-2 3.63µs ± 0% 2.37µs ± 0% -34.61% (p=0.001 n=7+7) MemclrRange/160K_228K-2 31.0µs ± 0% 30.6µs ± 1% -1.50% (p=0.001 n=7+7) [Geo mean] 1.97µs 1.76µs -10.59% name old speed new speed delta Memclr/5-2 1.98GB/s ± 0% 1.98GB/s ± 0% +0.27% (p=0.001 n=7+7) Memclr/16-2 5.78GB/s ± 0% 6.28GB/s ± 0% +8.67% (p=0.001 n=7+7) Memclr/64-2 20.2GB/s ± 0% 20.3GB/s ± 0% ~ (p=0.535 n=7+7) Memclr/256-2 35.3GB/s ± 0% 35.2GB/s ± 0% ~ (p=0.259 n=7+7) Memclr/4096-2 83.1GB/s ± 0% 94.2GB/s ± 0% +13.39% (p=0.001 n=7+7) Memclr/65536-2 49.7GB/s ± 1% 53.0GB/s ± 0% +6.73% (p=0.001 n=7+7) Memclr/1M-2 38.4GB/s ± 0% 39.4GB/s ± 4% ~ (p=0.209 n=7+7) Memclr/4M-2 21.5GB/s ± 0% 28.4GB/s ± 4% +32.02% (p=0.001 n=7+7) Memclr/8M-2 21.5GB/s ± 0% 27.2GB/s ± 0% +26.73% (p=0.001 n=7+6) Memclr/16M-2 21.4GB/s ± 0% 26.2GB/s ± 1% +22.42% (p=0.001 n=7+7) Memclr/64M-2 23.7GB/s ± 1% 23.7GB/s ± 1% ~ (p=0.620 n=7+7) MemclrRange/1K_2K-2 77.3GB/s ± 0% 77.3GB/s ± 0% ~ (p=0.710 n=7+7) MemclrRange/2K_8K-2 85.7GB/s ± 0% 107.1GB/s ± 0% +25.00% (p=0.001 n=6+7) MemclrRange/4K_16K-2 89.0GB/s ± 0% 136.1GB/s ± 0% +52.92% (p=0.001 n=7+7) MemclrRange/160K_228K-2 53.6GB/s ± 0% 54.4GB/s ± 1% +1.52% (p=0.001 n=7+7) [Geo mean] 29.2GB/s 32.7GB/s +11.86% Change-Id: I8f3533f88ebd303ae1666a77391fec304bea9724 Reviewed-on: https://go-review.googlesource.com/c/go/+/374396 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
A successful invocation of the hostname command prints the hostname to stdout and exits with code 0. No part of the hostname is printed to stderr, so don't consider it. This avoids false positive failures in environments where hostname prints some extraneous information (such as performance warnings) to stderr, and makes the test a bit more robust. Fixes #52781. Change-Id: I46aa6fbf95b6616bacf9c2b5e412b0851b230744 Reviewed-on: https://go-review.googlesource.com/c/go/+/405014 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Jason Donenfeld <Jason@zx2c4.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes #52798. Fixes #51441 (until proven otherwise 😅). Change-Id: Ic1eadebd0d41c5cbe37340190f8b2bde4b6c5673 Reviewed-on: https://go-review.googlesource.com/c/go/+/405214 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 394576 removed FuncBody, which is the only caller of CheckUnused and CheckReturn. CL 394556 removed all usages of curpkg. controlLabel was added (un-intentionally?) in Cl 277920 but never used. Change-Id: I7f47f93b4b9ae9c1a681ff4717920f8d2e7c19c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/405094 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
The current value is appropriate for an early in-house version of Linux/LoongArch, but for the upstream version it is very likely "LINUX_5.10" instead, per the latest upstream submission [1]. [1]: https://lore.kernel.org/all/20220518095709.1313120-3-chenhuacai@loongson.cn/ Change-Id: Ia97e5cae82a5b306bd3eea86b9e442441da07973 Reviewed-on: https://go-review.googlesource.com/c/go/+/407755 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
…c key type
For map composite literals where the key type is a suitably constrained
type parameter, the existing key duplicate detection mechanism doesn't
work when the keys are numeric values of different types but equal value.
For instance, given
func _[P int64|float64]() {
_ = map[P]string{0: "foo", 0.0: "bar"}
}
the key values 0 and 0.0 have the same numeric value 0 but currently
are treated as different values int64(0) and float64(0.0). For any
valid instantiation of P, the keys will collide.
This CL changes the keyVal function to map numeric types to the
"smallest" numeric type in which a value can be represented. For
instance, float64(0.0) is mapped to int64(0). This ensures that
numerically equal values are always represented the same way so
that they can be detected as duplicates.
Fixes #51610.
Change-Id: I3eb71142bbe6b13453282a7f71ee48950e58ecbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/406555
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The divisor must be non-zero for the rule to be triggered. Fixes #53018 Change-Id: Id56b8d986945bbb66e13131d11264ee438de5cb2 Reviewed-on: https://go-review.googlesource.com/c/go/+/407655 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: WANG Xuerui <git@xen0n.name>
Co-authored-by: limeidan <limeidan@loongson.cn> Change-Id: Iac4f706fc9ff1047f1fa02f7178ebfbe38ad1ec3 Reviewed-on: https://go-review.googlesource.com/c/go/+/407754 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: WANG Xuerui <git@xen0n.name> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Co-authored-by: limeidan <limeidan@loongson.cn> Change-Id: I0011a10f831e6c2b0da96265682212b0747f0e2a Reviewed-on: https://go-review.googlesource.com/c/go/+/407774 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
os/signal.Notify requires that "the caller must ensure that c has sufficient buffer space to keep up with the expected signal rate" as it does a nonblocking send when it receives a signal. The test currently using a unbuffered channel, which means it may miss the signal if the signal arrives before the channel receive operation. Fixes #52998. Change-Id: Icdcab9396d735506480ef880fb45a4669fa7cc8f Reviewed-on: https://go-review.googlesource.com/c/go/+/407888 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
…d any Use the existing versionErrorf mechanism to report use of undeclared any and comparable. Also, port versionErrorf mechanism to go/types and use it in this case as well. Adjust tests as needed. For #52880. Change-Id: I6a646f16a849692ee0cb57e362d5f3d77e2c25f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/407896 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Add cycle detection to hasVarType to avoid infinite recursions caused by invalid cyclic types. This catches cases where the validType check has not yet run or has checked differently instantiated types. As an alternative, validType could mark invalid *Named types by setting their underlying types to Typ[Invalid]. That does work but discards information which leads to undesired effects with other errors. A better mechanism might be to explicitly track in *Named if a type is invalid and why it is invalid, and connect that with a general validity attribute on types. That's a more invasive change we might consider down the road. Fixes #52915. Change-Id: I9e798b348f4a88b1655e1ff422bd50aaefd9dc50 Reviewed-on: https://go-review.googlesource.com/c/go/+/406849 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
The Read method on the Body returned from a net/http.Transport does not wrap errors returned by the underlying io.Reader and returns a bare io.ErrUnexpectedEOF if the body is shorter than the declared Content-Length. Since we can't feasibly add detail on the net/http side without breaking established users, we must instead add detail on the caller side. Since the net/http client uses url.Error for most of its own errors, we use that same error type here. I have not added a regression test for this change. (While it is theoretically possible to set up a GOPROXY that returns incorrect Content-Length headers, the change seems straightforward enough that it isn't worth the complex test setup.) Fixes #52727. Change-Id: Id00b04ae4fd518148106a49188fe169aadbcce2c Reviewed-on: https://go-review.googlesource.com/c/go/+/406675 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
The resolved status of a Named type should be owned by its API, and callers should access resolved data via methods. Remove several instances where Named.resolve is explicitly invoked, only to be followed by a method that also resolves. Also make two minor cleanups: - Remove the tparams parameter to Checker.newNamed, as it was unused. - Include position information when assertions fail, so that one doesn't need to go digging in the panicking stack to find the assertion location. Updates #52728 Change-Id: Icbe8c89e9cfe02d60af7d9ba907eaebe1f00193e Reviewed-on: https://go-review.googlesource.com/c/go/+/404874 Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes #53041 Change-Id: If6580c8f0f14edfdc297d3239a7767ce0570ff79 Reviewed-on: https://go-review.googlesource.com/c/go/+/407975 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Rob Pike <r@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
If a function type has no type parameters, note when it is visited and do not recur. (It must be visited at least once because of closures and their associated types occurring in a generic context). Fixes #51832. Change-Id: Iee20612ffd0a03b838b9e59615f4a0206fc8940b Reviewed-on: https://go-review.googlesource.com/c/go/+/406714 Reviewed-by: Keith Randall <khr@google.com>
This updates the release notes with TODOs using relnote. It also changes all refrences of golang.org to go.dev. For #51400. Change-Id: I8a210140483aed7c41fe47242041e4b363e2eb10 Reviewed-on: https://go-review.googlesource.com/c/go/+/408217 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Carlos Amedee <carlos@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
…":". Fixes #52476 Change-Id: I9eb72ac7dbccd6322d060291f31831dc389eb9bb Reviewed-on: https://go-review.googlesource.com/c/go/+/401595 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5291216d5416eccd5a67b45b2f32cf2932b3747f Reviewed-on: https://go-review.googlesource.com/c/go/+/407974 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
|
This PR (HEAD: 025ea0e) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/408534 to see it. Tip: You can toggle comments from me using the |
|
Message from Gopher Robot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/408534. |
|
Message from Ian Lance Taylor: Patch Set 1: (5 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/408534. |
|
This PR (HEAD: 50fb0f8) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/408534 to see it. Tip: You can toggle comments from me using the |
stevemk14ebr
changed the title
|
This PR (HEAD: 4fbe3ff) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/408534 to see it. Tip: You can toggle comments from me using the |
|
Message from Zeke Lu: Patch Set 5: (2 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/408534. |
|
This PR (HEAD: dea9907) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/408534 to see it. Tip: You can toggle comments from me using the |
|
Message from Zeke Lu: Patch Set 7: (2 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/408534. |
stevemk14ebr
changed the title
|
This is a mess now, I'm just going to re-open this with the correct commit author. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the section flag checks in buildinfo. The elf flag check was wrong too but it's never hit due to the symbol resolution just above, which is usually valid for non-stripped binaries.
Fixes #53071