Skip to content

cmd/compile: evaluating range argument in cases we shouldn't #73476

Closed
@randall77

Description

@randall77

After CL 659317 and 658097, we should no longer be evaluating the side-effects of array and ptr-to-array args to range statements. So code like this should not fault:

package main

//go:noinline
func f(p *[4]int) {
	for i := range *p {
		println(i)
	}
}
func main() {
	f(nil)
}

However, code like this does fault:

package main

//go:noinline
func f(p *[4]int) {
	for i := range (*p) {
		println(i)
	}
}
func main() {
	f(nil)
}

Note the extra parentheses. Normally those aren't there, as gofmt removes them. But cgo puts those parentheses there, which somehow confuses the detector that decides whether we need to evaluate the side-effects of the range statement argument or not.

@cuonglm This relates to the windows/race detector bug. That still I believe a real bug in the race detector, but the reason why it is calling racereadrange at all is this bug.

Metadata

Metadata

Assignees

Labels

BugReportIssues describing a possible bug in the Go implementation.compiler/runtimeIssues related to the Go compiler and/or runtime.

Type

No type

Projects

Status

Done

Relationships

None yet

Development

No branches or pull requests

Issue actions