go/test/fixedbugs/issue20780.go

26 строки
755 B
Go
Исходник Постоянная ссылка Обычный вид История

// errorcheck
// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// We have a limit of 1GB for stack frames.
// Make sure we include the callee args section.
package main
[dev.regabi] cmd/compile: deref PAUTOHEAPs during SSA construction Currently, during walk we rewrite PAUTOHEAP uses into derefs of their corresponding Heapaddr, but we can easily do this instead during SSA construction. This does involve updating two test cases: * nilptr3.go This file had a test that we emit a "removed nil check" diagnostic for the implicit dereference from accessing a PAUTOHEAP variable. This CL removes this diagnostic, since it's not really useful to end users: from the user's point of view, there's no pointer anyway, so they needn't care about whether we check for nil or not. That's a purely internal detail. And with the PAUTOHEAP dereference handled during SSA construction, we can more robustly ensure this happens, rather than relying on setting a flag in walk and hoping that SSA sees it. * issue20780.go Previously, when PAUTOHEAPs were dereferenced during walk, it had a consequence that when they're passed as a function call argument, they would first get copied to the stack before being copied to their actual destination. Moving the dereferencing to SSA had a side-effect of eliminating this unnecessary temporary, and copying directly to the destination parameter. The test is updated to instead call "g(h(), h())" where h() returns a large value, as the first result will always need to be spilled somewhere will calling the second function. Maybe eventually we're smart enough to realize it can be spilled to the heap, but we don't do that today. Because I'm concerned that the direct copy-to-parameter optimization could interfere with race-detector instrumentation (e.g., maybe the copies were previously necessary to ensure they're not clobbered by inserted raceread calls?), I've also added issue20780b.go to exercise this in a few different ways. Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d Reviewed-on: https://go-review.googlesource.com/c/go/+/281293 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-01-04 06:49:49 +03:00
type Big = [400e6]byte
test: match gofrontend error messages fixedbugs/issue20602.go:13:9: error: argument must have complex type fixedbugs/issue20602.go:14:9: error: argument must have complex type fixedbugs/issue19323.go:12:12: error: attempt to slice object that is not array, slice, or string fixedbugs/issue19323.go:18:13: error: attempt to slice object that is not array, slice, or string fixedbugs/issue20749.go:12:11: error: array index out of bounds fixedbugs/issue20749.go:15:11: error: array index out of bounds fixedbugs/issue20415.go:14:5: error: redefinition of ‘f’ fixedbugs/issue20415.go:12:5: note: previous definition of ‘f’ was here fixedbugs/issue20415.go:25:5: error: redefinition of ‘g’ fixedbugs/issue20415.go:20:5: note: previous definition of ‘g’ was here fixedbugs/issue20415.go:33:5: error: redefinition of ‘h’ fixedbugs/issue20415.go:31:5: note: previous definition of ‘h’ was here fixedbugs/issue19977.go:12:21: error: reference to undefined name ‘a’ fixedbugs/issue20812.go:10:13: error: invalid type conversion (cannot use type string as type int) fixedbugs/issue20812.go:11:13: error: invalid type conversion (cannot use type int as type bool) fixedbugs/issue20812.go:12:13: error: invalid type conversion (cannot use type string as type bool) fixedbugs/issue20812.go:13:13: error: invalid type conversion (cannot use type bool as type int) fixedbugs/issue20812.go:14:13: error: invalid type conversion (cannot use type bool as type string) fixedbugs/issue21256.go:9:5: error: redefinition of ‘main’ fixedbugs/issue20813.go:10:11: error: invalid left hand side of assignment fixedbugs/issue20185.go:22:16: error: ‘t’ declared but not used fixedbugs/issue20185.go:13:9: error: cannot type switch on non-interface value fixedbugs/issue20185.go:22:9: error: cannot type switch on non-interface value fixedbugs/issue20227.go:11:11: error: division by zero fixedbugs/issue20227.go:12:12: error: division by zero fixedbugs/issue20227.go:13:12: error: division by zero fixedbugs/issue20227.go:15:11: error: division by zero fixedbugs/issue20227.go:16:12: error: division by zero fixedbugs/issue19880.go:14:13: error: invalid use of type fixedbugs/issue23093.go:9:5: error: initialization expression for ‘f’ depends upon itself fixedbugs/issue21979.go:29:13: error: integer constant overflow fixedbugs/issue21979.go:39:13: error: complex constant truncated to floating-point fixedbugs/issue21979.go:10:13: error: invalid type conversion (cannot use type string as type bool) fixedbugs/issue21979.go:11:13: error: invalid type conversion (cannot use type int as type bool) fixedbugs/issue21979.go:12:13: error: invalid type conversion (cannot use type float64 as type bool) fixedbugs/issue21979.go:13:13: error: invalid type conversion (cannot use type complex128 as type bool) fixedbugs/issue21979.go:15:13: error: invalid type conversion (cannot use type bool as type string) fixedbugs/issue21979.go:17:13: error: invalid type conversion (cannot use type float64 as type string) fixedbugs/issue21979.go:18:13: error: invalid type conversion (cannot use type complex128 as type string) fixedbugs/issue21979.go:20:13: error: invalid type conversion (cannot use type string as type int) fixedbugs/issue21979.go:21:13: error: invalid type conversion (cannot use type bool as type int) fixedbugs/issue21979.go:27:13: error: invalid type conversion (cannot use type string as type uint) fixedbugs/issue21979.go:28:13: error: invalid type conversion (cannot use type bool as type uint) fixedbugs/issue21979.go:34:13: error: invalid type conversion (cannot use type string as type float64) fixedbugs/issue21979.go:35:13: error: invalid type conversion (cannot use type bool as type float64) fixedbugs/issue21979.go:41:13: error: invalid type conversion (cannot use type string as type complex128) fixedbugs/issue21979.go:42:13: error: invalid type conversion (cannot use type bool as type complex128) fixedbugs/issue21988.go:11:11: error: reference to undefined name ‘Wrong’ fixedbugs/issue22063.go:11:11: error: reference to undefined name ‘Wrong’ fixedbugs/issue22904.go:12:6: error: invalid recursive type ‘a’ fixedbugs/issue22904.go:13:6: error: invalid recursive type ‘b’ fixedbugs/issue22921.go:11:16: error: reference to undefined identifier ‘bytes.nonexist’ fixedbugs/issue22921.go:13:19: error: reference to undefined identifier ‘bytes.nonexist’ fixedbugs/issue22921.go:13:19: error: expected signature or type name fixedbugs/issue22921.go:17:15: error: reference to undefined identifier ‘bytes.buffer’ fixedbugs/issue23823.go:15:9: error: invalid recursive interface fixedbugs/issue23823.go:10:9: error: invalid recursive interface fixedbugs/issue23732.go:24:13: error: too few expressions for struct fixedbugs/issue23732.go:34:17: error: too many expressions for struct fixedbugs/issue23732.go:37:13: error: too few expressions for struct fixedbugs/issue23732.go:40:17: error: too many expressions for struct fixedbugs/issue22794.go:16:14: error: reference to undefined field or method ‘floats’ fixedbugs/issue22794.go:18:19: error: unknown field ‘floats’ in ‘it’ fixedbugs/issue22794.go:19:17: error: unknown field ‘InneR’ in ‘it’ fixedbugs/issue22794.go:18:9: error: ‘i2’ declared but not used fixedbugs/issue22822.go:15:17: error: expected function fixedbugs/issue25727.go:12:10: error: reference to unexported field or method ‘doneChan’ fixedbugs/issue25727.go:13:10: error: reference to undefined field or method ‘DoneChan’ fixedbugs/issue25727.go:14:21: error: unknown field ‘tlsConfig’ in ‘http.Server’ fixedbugs/issue25727.go:15:21: error: unknown field ‘DoneChan’ in ‘http.Server’ fixedbugs/issue25727.go:21:14: error: unknown field ‘bAr’ in ‘foo’ Change-Id: I32ce0b7d80017b2367b8fb479a881632240d4161 Reviewed-on: https://go-review.googlesource.com/c/go/+/277455 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2020-12-14 09:48:02 +03:00
func f() { // GC_ERROR "stack frame too large"
[dev.regabi] cmd/compile: deref PAUTOHEAPs during SSA construction Currently, during walk we rewrite PAUTOHEAP uses into derefs of their corresponding Heapaddr, but we can easily do this instead during SSA construction. This does involve updating two test cases: * nilptr3.go This file had a test that we emit a "removed nil check" diagnostic for the implicit dereference from accessing a PAUTOHEAP variable. This CL removes this diagnostic, since it's not really useful to end users: from the user's point of view, there's no pointer anyway, so they needn't care about whether we check for nil or not. That's a purely internal detail. And with the PAUTOHEAP dereference handled during SSA construction, we can more robustly ensure this happens, rather than relying on setting a flag in walk and hoping that SSA sees it. * issue20780.go Previously, when PAUTOHEAPs were dereferenced during walk, it had a consequence that when they're passed as a function call argument, they would first get copied to the stack before being copied to their actual destination. Moving the dereferencing to SSA had a side-effect of eliminating this unnecessary temporary, and copying directly to the destination parameter. The test is updated to instead call "g(h(), h())" where h() returns a large value, as the first result will always need to be spilled somewhere will calling the second function. Maybe eventually we're smart enough to realize it can be spilled to the heap, but we don't do that today. Because I'm concerned that the direct copy-to-parameter optimization could interfere with race-detector instrumentation (e.g., maybe the copies were previously necessary to ensure they're not clobbered by inserted raceread calls?), I've also added issue20780b.go to exercise this in a few different ways. Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d Reviewed-on: https://go-review.googlesource.com/c/go/+/281293 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-01-04 06:49:49 +03:00
// Note: This test relies on the fact that we currently always
// spill function-results to the stack, even if they're so
// large that we would normally heap allocate them. If we ever
// improve the backend to spill temporaries to the heap, this
// test will probably need updating to find some new way to
// construct an overly large stack frame.
g(h(), h())
}
[dev.regabi] cmd/compile: deref PAUTOHEAPs during SSA construction Currently, during walk we rewrite PAUTOHEAP uses into derefs of their corresponding Heapaddr, but we can easily do this instead during SSA construction. This does involve updating two test cases: * nilptr3.go This file had a test that we emit a "removed nil check" diagnostic for the implicit dereference from accessing a PAUTOHEAP variable. This CL removes this diagnostic, since it's not really useful to end users: from the user's point of view, there's no pointer anyway, so they needn't care about whether we check for nil or not. That's a purely internal detail. And with the PAUTOHEAP dereference handled during SSA construction, we can more robustly ensure this happens, rather than relying on setting a flag in walk and hoping that SSA sees it. * issue20780.go Previously, when PAUTOHEAPs were dereferenced during walk, it had a consequence that when they're passed as a function call argument, they would first get copied to the stack before being copied to their actual destination. Moving the dereferencing to SSA had a side-effect of eliminating this unnecessary temporary, and copying directly to the destination parameter. The test is updated to instead call "g(h(), h())" where h() returns a large value, as the first result will always need to be spilled somewhere will calling the second function. Maybe eventually we're smart enough to realize it can be spilled to the heap, but we don't do that today. Because I'm concerned that the direct copy-to-parameter optimization could interfere with race-detector instrumentation (e.g., maybe the copies were previously necessary to ensure they're not clobbered by inserted raceread calls?), I've also added issue20780b.go to exercise this in a few different ways. Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d Reviewed-on: https://go-review.googlesource.com/c/go/+/281293 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-01-04 06:49:49 +03:00
func g(Big, Big)
func h() Big