cmd/compile: Extra bounds checking when using addition in condition/index

[fice-t]

Go version

go version go1.26-devel_5241d11 Mon Nov 10 12:48:05 2025 -0800 linux/amd64

Output of go env in your module/workspace:

Workspace is `go.godbolt.org` on `x86-64 gc (tip)` as above.

What did you do?

(Code/output used also found here)

Compile containsDotDot from the standard library:

func containsDotDot(s string) bool {
	if len(s) < 2 {
		return false
	}
	for i := 0; i < len(s)-1; i++ {
		if s[i] == '.' && s[i+1] == '.' {
			return true
		}
	}
	return false
}

What did you see happen?

A bounds check + panic section was generated:

        TEXT    command-line-arguments.containsDotDot(SB), NOSPLIT|ABIInternal, $8-16
        [...]
        CMPQ    BX, $2
        JLT     command-line-arguments_containsDotDot_pc19
        XORL    CX, CX
        JMP     command-line-arguments_containsDotDot_pc26
command-line-arguments_containsDotDot_pc19:
        XORL    AX, AX
        POPQ    BP
        RET
command-line-arguments_containsDotDot_pc23:
        INCQ    CX
command-line-arguments_containsDotDot_pc26:
        LEAQ    -1(BX), DX
        NOP
        CMPQ    CX, DX
        JGE     command-line-arguments_containsDotDot_pc76
        MOVBLZX (AX)(CX*1), DX
        CMPB    DL, $46
        JNE     command-line-arguments_containsDotDot_pc23
        LEAQ    1(CX), DX
        CMPQ    BX, DX
        JLS     command-line-arguments_containsDotDot_pc80 ; <--------------------------
        MOVBLZX 1(CX)(AX*1), DX
        NOP
        CMPB    DL, $46
        JNE     command-line-arguments_containsDotDot_pc23
        MOVL    $1, AX
        POPQ    BP
        RET
command-line-arguments_containsDotDot_pc76:
        XORL    AX, AX
        POPQ    BP
        RET
command-line-arguments_containsDotDot_pc80:
        PCDATA  $1, $1
        PCDATA  $4, $3663
        CALL    runtime.panicBounds(SB)
        XCHGL   AX, AX

What did you expect to see?

No bounds check + panic section should be generated as the condition checks for i < len(s)-1, meaning i+1 < len(s).

There are two cases below illustrating the effects of what should be equivalent assembly output:

Case 1: Change of variable (j := i + 1)

This results in no extra bounds checking:

func containsDotDot(s string) bool {
	if len(s) < 2 {
		return false
	}
	for j := 1; j < len(s); j++ {
		if s[j-1] == '.' && s[j] == '.' {
			return true
		}
	}
	return false
}

Case 2: Move of constant to other side of condition

This results in both index operations having bounds checks:

func containsDotDot(s string) bool {
	if len(s) < 2 {
		return false
	}
	for i := 0; i+1 < len(s); i++ {
		if s[i] == '.' && s[i+1] == '.' {
			return true
		}
	}
	return false
}

[randall77]

Currently our prove pass can't deduce in bounds from i >= 0 && i < len(s)-1 together with s[i+1]. It doesn't realize the -1/+1 cancel. It could.

for i := 0; i+1 < len(s); i++ is a little bit harder because we need to make sure i+1 doesn't overflow. That's deducible in this case, I think, but is an extra step.

[gabyhelp]

Related Issues

• cmd/compile: prove only notices one of a pair of induction variables (missed optimization) #76269
• cmd/compile: missing BCE when index is modulo len #54755 (closed)
• cmd/compile: missed trivial bound check elimination #66826 (closed)
• cmd/compile: eliminate more bounds checks #17370
• cmd/compile: unnecessary bounds checking using result of intrinsic function #58334 (closed)
• cmd/compile: missing BCE in range expression #54753 (closed)
• cmd/compile: bound-check elimination does not propagate slice length equality correctly #75144 (closed)
• cmd/compile: lack of BCE in for loops without inline increment #75184 (closed)
• cmd/compile: index out of bounds in code the compiler can prove is never executed #56667 (closed)
• cmd/compile: negative types are allowed, but will not be negative during program execution, with boundary checking #64895

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[JunyangShao]

@golang/compiler

[fice-t]

Currently our prove pass can't deduce in bounds from i >= 0 && i < len(s)-1 together with s[i+1]. It doesn't realize the -1/+1 cancel. It could.

Hopefully it could even handle ranges instead of just cancellation. For example:

func containsDotDotDot(s string) bool {
    for i := 0; i < len(s)-2; i++ {
		if s[i] == '.' && s[i+1] == '.' && s[i+2] == '.' {
			return true
		}
	}
	return false
}

The compiler should recognize that i+1 will always be within range as well (substituting k := i+2 eliminates the bounds checks as expected).

for i := 0; i+1 < len(s); i++ is a little bit harder because we need to make sure i+1 doesn't overflow. That's deducible in this case, I think, but is an extra step.

Would the compiler be allowed change the addition to subtraction (for i := 0; i < len(s)-n; i++) to reduce it to the above? Or would that be against spec (is there a case where someone would want to allow overflow in such a check against length)?

[fice-t]

@randall77 In looking at similar issues I discovered that apparently the compiler can now deduce the first example, but just not for strings. For example:

// BC when s is string; no BC with slice/array!
func containsDotDot(s []byte) bool {
	for i := 0; i < len(s)-1; i++ {
		if s[i] == '.' && s[i+1] == '.' {
			return true
		}
	}
	return false
}

Similarly, the containsDotDotDot above does not have extra BCs when the argument is a slice/array.

Note that this is only for the dev branch; even slices/arrays have extra BCs on Go 1.24.

[fice-t]

@randall77 I may have found the culprit. Recently added was detectSliceLenRelation, however it contains the following lines:

	if !(v.Args[0].Op == OpSliceLen || v.Args[0].Op == OpSliceCap) {
		return
	}

I would guess that detectSliceLenRelation should also apply to OpStringLen as well, which would hopefully make the first example work for strings.

Edit: checkForChunkedIndexBounds also excludes OpStringLen.

[randall77]

@dr2chase