Just a guess, but can you try to use b := make([]byte, len(s)) instead of MakeNoZero to see if the failure goes away?

Just a guess, but can you try to use b := make([]byte, len(s)) instead of MakeNoZero to see if the failure goes away?

I will try again later. I am currently trying git bisect and I have noticed that race is required for ICE to appear.

Just a guess, but can you try to use b := make([]byte, len(s)) instead of MakeNoZero to see if the failure goes away?

After trying your guess, still ICE.
internal\bytealg\bytealg.go:177:6: internal compiler error: 'CloneString': value .autotmp_11 (v97) incorrectly live at entry

Due to the presence of internal/cpu and<ABIInternal>, I use the following code for git bisect.
cat bytealg.go

// 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.

package bytealg

import (
        "unsafe"
)

// MakeNoZero makes a slice of length and capacity n without zeroing the bytes.
// It is the caller's responsibility to ensure uninitialized bytes
// do not leak to the end user.
func MakeNoZero(n int) []byte {
        return nil
}

// Clone returns a copy of b[:len(b)].
// The result may have additional unused capacity.
// Clone(nil) returns nil.
func Clone(s []byte) []byte {
        if s == nil {
                return nil
        }
        return append([]byte{}, s...)
}

// CloneString returns a fresh copy of s.
// It guarantees to make a copy of s into a new allocation,
// which can be important when retaining only a small substring
// of a much larger string. Using Clone can help such programs
// use less memory. Of course, since using Clone makes a copy,
// overuse of Clone can make programs use more memory.
// Clone should typically be used only rarely, and only when
// profiling indicates that it is needed.
// For strings of length zero the string "" will be returned
// and no allocation is made.
func CloneString(s string) string {
        if len(s) == 0 {
                return ""
        }
        b := MakeNoZero(len(s))
        copy(b, s)
        return unsafe.String(&b[0], len(b))
}

Failed to re ICE.

I believe there is something going on with copy, if you replace the copy with an append it works even with -race:

diff --git a/src/internal/bytealg/bytealg.go b/src/internal/bytealg/bytealg.go
index 7d70b0b562..99faab7e9a 100644
--- a/src/internal/bytealg/bytealg.go
+++ b/src/internal/bytealg/bytealg.go
@@ -178,7 +178,6 @@ func CloneString(s string) string {
 	if len(s) == 0 {
 		return ""
 	}
-	b := MakeNoZero(len(s))
-	copy(b, s)
+	b := append([]byte{}, s...)
 	return unsafe.String(&b[0], len(b))
 }

This is less performant and also does a shallow copy.

I was unable to put together a reproducible case outside of the one from the CL

cc @golang/compiler

Strictly speaking, a bug in your CL (even if it is caused by existing weirdness in the compiler/library you are patching) is not a bug in the current compiler. I'd like to close this to avoid cluttering up the dashboard.

Strictly speaking, a bug in your CL (even if it is caused by existing weirdness in the compiler/library you are patching) is not a bug in the current compiler. I'd like to close this to avoid cluttering up the dashboard.

This ICE caused CL to be blocked. I have encountered this situation for the first time. How can I solve it?

@qiulaidongfeng best bet would be to try and isolate the ICE to get a reproducible example that does not depend on your CL so it can be addressed as a compiler bug.

Note that internal/bytealg is treated as a runtime package by the compiler, so you may need to do special handling if you do un-usual thing.