runtime/internal/atomic: remove write barrier from Storep1 on s390x

atomic.Storep1 is not supposed to invoke a write barrier (that's what
atomicstorep is for), but currently does on s390x. This causes a panic
in runtime.mapzero when it tries to use atomic.Storep1 to store what's
actually a scalar.

Fix this by eliminating the write barrier from atomic.Storep1 on
s390x. Also add some documentation to atomicstorep to explain the
difference between these.

Fixes #15270.

Change-Id: I291846732d82f090a218df3ef6351180aff54e81
Reviewed-on: https://go-review.googlesource.com/21993
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Munday <munday@ca.ibm.com>

src/runtime/atomic_pointer.go

@@ -15,10 +15,9 @@ import (
 // escape analysis decisions about the pointer value being stored.
 // Instead, these are wrappers around the actual atomics (casp1 and so on)
 // that use noescape to convey which arguments do not escape.
-//
-// Additionally, these functions must update the shadow heap for
-// write barrier checking.
 
+// atomicstorep performs *ptr = new atomically and invokes a write barrier.
+//
 //go:nosplit
 func atomicstorep(ptr unsafe.Pointer, new unsafe.Pointer) {
 	atomic.Storep1(noescape(ptr), new)

src/runtime/internal/atomic/atomic_s390x.go

@@ -40,7 +40,7 @@ func Store64(ptr *uint64, val uint64) {
 //go:noinline
 //go:nosplit
 func Storep1(ptr unsafe.Pointer, val unsafe.Pointer) {
-	*(*unsafe.Pointer)(ptr) = val
+	*(*uintptr)(ptr) = uintptr(val)
 }
 
 //go:noescape