{"action":"opened","issue":{"url":"https://api.github.com/repos/golang/go/issues/19907","repository_url":"https://api.github.com/repos/golang/go","labels_url":"https://api.github.com/repos/golang/go/issues/19907/labels{/name}","comments_url":"https://api.github.com/repos/golang/go/issues/19907/comments","events_url":"https://api.github.com/repos/golang/go/issues/19907/events","html_url":"https://github.com/golang/go/issues/19907","id":220660434,"number":19907,"title":"cmd/compile: regression in recent change to improve LoweredMove on ppc64x","user":{"login":"laboger","id":9433228,"avatar_url":"https://avatars2.githubusercontent.com/u/9433228?v=3","gravatar_id":"","url":"https://api.github.com/users/laboger","html_url":"https://github.com/laboger","followers_url":"https://api.github.com/users/laboger/followers","following_url":"https://api.github.com/users/laboger/following{/other_user}","gists_url":"https://api.github.com/users/laboger/gists{/gist_id}","starred_url":"https://api.github.com/users/laboger/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laboger/subscriptions","organizations_url":"https://api.github.com/users/laboger/orgs","repos_url":"https://api.github.com/users/laboger/repos","events_url":"https://api.github.com/users/laboger/events{/privacy}","received_events_url":"https://api.github.com/users/laboger/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-04-10T14:21:39Z","updated_at":"2017-04-10T14:21:39Z","closed_at":null,"body":"Please answer these questions before submitting your issue. Thanks!\r\n\r\n### What version of Go are you using (`go version`)?\r\ngo tip\r\n\r\n### What operating system and processor architecture are you using (`go env`)?\r\nUbuntu ppc64le\r\n\r\n### What did you do?\r\nBuilt a golang from master, then tried to use it to do 'go get' on a ppc64le machine.\r\n\r\n### What did you expect to see?\r\nCorrect execution\r\n\r\n### What did you see instead?\r\ngo get -u golang.org/x/sys/unix\r\npanic: runtime error: invalid memory address or nil pointer dereference\r\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]\r\n\r\ngoroutine 35 [running]:\r\npanic(0x3b50a0, 0x684fd0)\r\n\t/home/boger/golang/base/go/src/runtime/panic.go:531 +0x3e4\r\nruntime.panicmem()\r\n\t/home/boger/golang/base/go/src/runtime/panic.go:63 +0x64\r\nruntime.sigpanic()\r\n\t/home/boger/golang/base/go/src/runtime/signal_unix.go:348 +0x258\r\ncreated by net/http.(*http2Transport).newClientConn\r\n\t/home/boger/golang/base/go/src/net/http/h2_bundle.go:6003 +0x568\r\n\r\nAfter much debugging, I found that the generated code for LoweredMove when the target is unaligned and the size is 4 or 8 the golang assembler is generating incorrect instructions, i.e., it is setting fields in the instruction that shouldn't be set.  In the above case, the bad code was found in processPing prior to the call to WritePing:\r\n\r\n  2ea5f8:       0c 00 a5 e8     ld      r5,12(r5)\r\n  **2ea5fc:       29 00 a1 f8     stdu    r5,40(r1)**\r\n  2ea600:       20 00 81 f8     std     r4,32(r1)\r\n  2ea604:       01 00 80 38     li      r4,1\r\n  2ea608:       28 00 81 98     stb     r4,40(r1)\r\n  2ea60c:       1d f6 fe 4b     bl      2d9c28 <net/http.(*http2Framer).WritePing>\r\n\r\nDoing a stdu based off r1 is really bad at this point because the stack gets messed up.  I found other cases where the assembler generates illegal instructions that result in a SIGILL at runtime.  This happens because some loads and stores are DS form instructions, while others are D form instructions.  Those with DS form instructions have a different sized field for the offset value, and require offsets that are a multiple of 4, but the D form instructions allow any offsets.  The assembler was treating all loads and stores as D form instructions and was not checking the offset's alignment.\r\n\r\nThere are two parts to this problem which I plan to fix with 2 CLs:\r\n1) Fix PPC64.rules so it no longer generates asm with incorrect offsets when the load or store is a DS form.  That fixes the regression, and I am continuing to test.\r\n2) Fix the assembler to detect the cases where loads and stores are DS form but are using incorrect offset values and generate an error.\r\n\r\nThere probably should be some additional testcases for this problem but not sure on the best place to put those.  "}}
{"actor":{"display_login":"laboger"}}