From d8e8fc292ace5ae59a0da44dfca1dd5b1a71ecf1 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Wed, 13 Apr 2016 11:13:39 -0400 Subject: 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 Run-TryBot: Austin Clements Reviewed-by: Michael Munday --- src/runtime/atomic_pointer.go | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'src/runtime/atomic_pointer.go') diff --git a/src/runtime/atomic_pointer.go b/src/runtime/atomic_pointer.go index bd21b49945..d54f1d6eef 100644 --- a/src/runtime/atomic_pointer.go +++ b/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) -- cgit v1.3