On Fri, Nov 20, 2020 at 1:03 PM 'Kevin Chowski' via golang-nuts <golang-nuts@googlegroups.com> wrote: > > Thanks Ian for the very quick reply! > > I see you're referencing this: > > > On ARM, x86-32, and 32-bit MIPS, it is the caller's responsibility to > > arrange for 64-bit alignment of 64-bit words accessed atomically. The first > > word in a variable or in an allocated struct, array, or slice can be relied > > upon to be 64-bit aligned. > > Yeah it's a little unfortunate that it doesn't say i386, I ctrl-f'd for > "i386" on the page too and I probably would have correctly read that sentence > if it were in there. Unfortunately I read that sentence multiple times but I > guess I missed the obvious "x86" in there; my brain saw "ARM 32 32-bit MIPS" > and misread it as "32-bit ARM and 32-bit MIPS". My mistake for sure.
Honestly I don't think it was your mistake. I think the docs are confusing. I think we should change the docs to say "i386", since that is what we use for a GOARCH value. I will do that if nobody beats me to it. Ian > On Friday, November 20, 2020 at 1:54:28 PM UTC-7 Ian Lance Taylor wrote: >> >> On Fri, Nov 20, 2020 at 12:48 PM 'Kevin Chowski' via golang-nuts >> <golan...@googlegroups.com> wrote: >> > >> > I am debugging an issue in which we are seeing a crash on an atomic >> > access; on go 1.14.7 and 1.15.2 this reproduces with the following error: >> > >> > > panic: runtime error: invalid memory address or nil pointer dereference >> > > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8049f7c] >> > >> > On gotip (go version devel +3fd4917 Fri Nov 20 20:02:47 2020 +0000 >> > linux/amd64) I see the following instead: >> > >> > > panic: unaligned 64-bit atomic operation >> > >> > (I'm glad the error message got better! Kudos to whomever did that.) >> > >> > My confusion is that I don't quite see this restriction being documented >> > in sync/atomic's docs: ctrl-f for "alignment" only reveals information >> > related to MIPS and ARM, whereas this issue is for Intel 386. Is this >> > working as intended (e.g. documentation bug) or is this something deeper? >> >> It's down at the very bottom of https://golang.org/pkg/sync/atomic, in >> the "Bugs" section, which for some reason refers to i386 using the >> name x86-32. >> >> Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/b92e1561-441a-4ff3-8d7c-6929801a0b9bn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU3W3yGCyxrRRon3pSS%3DLiEZHvxwkf%2B-NLKk37haCf6SQ%40mail.gmail.com.
