2021-04-11T12:01:40-c2d28a6/linux-ppc64-buildlet
2021-04-11T12:01:40-c2d28a6/linux-ppc64le-buildlet
2021-04-11T12:01:40-c2d28a6/linux-s390x-ibm
2020-11-18T01:06:06-4482a91/linux-ppc64-buildlet

The test calls testing.AllocsPerRun with a count of 1:
https://github.com/golang/text/blob/e328d63cff14134669501e0e154e4f141c784322/language/match_test.go#L245-L247

That pattern is basically guaranteed to be flaky: AllocsPerRun sets runtime.GOMAXPROCS to 1, but it doesn't have any way to prevent the runtime from descheduling a goroutine and performing an allocation somewhere in the background, and it isn't at all obvious that the test has enough control over its environment to guarantee that no other goroutine that might allocate can be scheduled at that point.

The test should be changed to use a number of runs large enough to average away the occasional noisy allocation.