strings: HasSuffix doesn't work correctly for multibyte runes in go 1.26

[hauntedness]

Go version

Go 1.26

Output of go env in your module/workspace:

NA

What did you do?

https://go.dev/play/p/TUJbmwO_Op3?v=gotip

// You can edit this code!
// Click here and start typing.
package main

import (
	"fmt"
	"strings"
)

func main() {
	fmt.Println(strings.HasSuffix("木瓜太香", "太香"))
}

What did you see happen?

I don't have a pc to verify for now. Someone shared this behavior,
And I can reproduce it on go playground

What did you expect to see?

true same as go 1.25

[mason23zh]

can confirm.
In Go 1.26:

	fmt.Println(strings.HasSuffix(str1, "世界")) //false

	str2 := "こんにちは"
	fmt.Println(strings.HasSuffix(str2, "ちは")) //false

	str3 := "спасибо"
	fmt.Println(strings.HasSuffix(str3, "ибо")) //false

	str4 := "café"
	fmt.Println(strings.HasSuffix(str4, "fé")) // true
	
	str5:="Hello"
	fmt.Println(strings.HasSuffix(str5, "lo")) // true

[randall77]

This bisects to https://go-review.googlesource.com/c/go/+/700816
@fengyoulin

[Nagato-Yuzuru]

Based on my testing, this issue only occurs in the Go Playground. It does not appear in normal compilation.
The issue should be string comparison rather than the HasSuffix method.
Test Code

package main

import (
	"fmt"
	"strings"
)

func main() {
	// Test 1: Original bug case
	s := "一二三四"
	suffix := "三四"
	fmt.Println("=== HasSuffix bug reproduction ===")
	fmt.Println("HasSuffix:", strings.HasSuffix(s, suffix))

	// Test 2: Isolate string == comparison
	slice := s[len(s)-len(suffix):]
	fmt.Println("len(s):", len(s))
	fmt.Println("len(suffix):", len(suffix))
	fmt.Printf("slice bytes: %x\n", []byte(slice))
	fmt.Printf("suffix bytes: %x\n", []byte(suffix))
	fmt.Println("slice == suffix:", slice == suffix)

	// Test 3: ASCII control - should always work
	fmt.Println("\n=== ASCII control ===")
	fmt.Println("HasSuffix(\"abcd\", \"cd\"):", strings.HasSuffix("abcd", "cd"))

	// Test 4: Various multibyte characters
	fmt.Println("\n=== Multibyte character tests ===")

	// 2-byte UTF-8 (Latin extended / Cyrillic: 0xC0-0xDF leading byte)
	fmt.Println("Cyrillic  HasSuffix(\"абвг\", \"вг\"):", strings.HasSuffix("абвг", "вг"))

	// 3-byte UTF-8 (CJK: 0xE0-0xEF leading byte)
	fmt.Println("Japanese  HasSuffix(\"あいうえ\", \"うえ\"):", strings.HasSuffix("あいうえ", "うえ"))

	// 4-byte UTF-8 (Emoji: 0xF0-0xF4 leading byte)
	fmt.Println("Emoji     HasSuffix(\"😀😁😂🤣\", \"😂🤣\"):", strings.HasSuffix("😀😁😂🤣", "😂🤣"))

	// Test 5: Direct byte-level comparison via loop
	fmt.Println("\n=== Manual byte comparison ===")
	b1 := []byte(slice)
	b2 := []byte(suffix)
	allEqual := len(b1) == len(b2)
	for i := 0; allEqual && i < len(b1); i++ {
		if b1[i] != b2[i] {
			allEqual = false
			fmt.Printf("  mismatch at byte %d: %02x vs %02x\n", i, b1[i], b2[i])
		}
	}
	fmt.Println("Manual byte-by-byte equal:", allEqual)

	// Test 6: Compare via string conversion from bytes
	fmt.Println("string([]byte) equal:", string(b1) == string(b2))
}

On 1.25:

=== HasSuffix bug reproduction ===
HasSuffix: true
len(s): 12
len(suffix): 6
slice bytes: e4b889e59b9b
suffix bytes: e4b889e59b9b
slice == suffix: true

=== ASCII control ===
HasSuffix("abcd", "cd"): true

=== Multibyte character tests ===
Cyrillic  HasSuffix("абвг", "вг"): true
Japanese  HasSuffix("あいうえ", "うえ"): true
Emoji     HasSuffix("😀😁😂🤣", "😂🤣"): true

=== Manual byte comparison ===
Manual byte-by-byte equal: true
string([]byte) equal: true

On 1.26:

=== HasSuffix bug reproduction ===
HasSuffix: false
len(s): 12
len(suffix): 6
slice bytes: e4b889e59b9b
suffix bytes: e4b889e59b9b
slice == suffix: false

=== ASCII control ===
HasSuffix("abcd", "cd"): true

=== Multibyte character tests ===
Cyrillic  HasSuffix("абвг", "вг"): true
Japanese  HasSuffix("あいうえ", "うえ"): false
Emoji     HasSuffix("😀😁😂🤣", "😂🤣"): true

=== Manual byte comparison ===
Manual byte-by-byte equal: true
string([]byte) equal: true

This issue appears to occur with 3-byte UTF-8 characters.

Compiling locally to WASM also works as expected.

[Nagato-Yuzuru]

I'm not sure, but I guess it has something to do with this update.

WebAssembly¶
The compiler now unconditionally makes use of the sign extension and non-trapping floating-point to integer conversion instructions. These features have been standardized since at least Wasm 2.0. The corresponding GOWASM settings, signext and satconv, are now ignored.

It looks like the 3-byte alignment case hits the buggy path if the memcmp tail processing uses instructions affected by the sign extension change.

[fengyoulin]

It seems that the Eq64 got lowered to a MOVLconst <bool> [0], I don't know why.

[gabyhelp]

Related Issues

• cmd/compile: strings.HasSuffix has extra bounds check (len(s)-delta) #76304 (closed)

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

[hauntedness]

@fengyoulin
Is this checked on windows？
Some people said they are also getting wrong result on windows.

[gopherbot]

Change https://go.dev/cl/745581 mentions this issue: cmd/compile: avoid folding 64-bit integers into 32-bit constants

[seankhliao]

@gopherbot please open a backport issue for go 1.26