code review 102820043: cmd/gc: fix x=x crash

cmd/gc: fix x=x crash The 'nodarg' function is used to obtain a Node* representing a function argument or result. It returned a brand new Node*, but that violates the guarantee in most places in the compiler that two Node*s refer to the same variable if and only if they are the same Node* pointer. Reestablish that invariant by making nodarg return a preexisting named variable if present. Having fixed that, avoid any copy during x=x in componentgen, because the VARDEF we emit before the copy marks the lhs x as dead incorrectly. The change in walk.c avoids modifying the result of nodarg. This was the only place in the compiler that did so. Fixes issue 8097.

[rsc, 2014-05-28 21:18:54]

Hello golang-codereviews@googlegroups.com (cc: iant, khr, r), I'd like you to review this change to https://code.google.com/p/go/

[r, 2014-05-28 21:23:36]

LGTM but i am not an expert here

[khr, 2014-05-28 22:13:47]

On 2014/05/28 21:23:36, r wrote: > LGTM but i am not an expert here LGTM.

[rsc, 2014-05-28 23:50:22]

*** Submitted as https://code.google.com/p/go/source/detail?r=b0ce6dbafc18 *** cmd/gc: fix x=x crash The 'nodarg' function is used to obtain a Node* representing a function argument or result. It returned a brand new Node*, but that violates the guarantee in most places in the compiler that two Node*s refer to the same variable if and only if they are the same Node* pointer. Reestablish that invariant by making nodarg return a preexisting named variable if present. Having fixed that, avoid any copy during x=x in componentgen, because the VARDEF we emit before the copy marks the lhs x as dead incorrectly. The change in walk.c avoids modifying the result of nodarg. This was the only place in the compiler that did so. Fixes issue 8097. LGTM=r, khr R=golang-codereviews, r, khr CC=golang-codereviews, iant https://codereview.appspot.com/102820043

[gobot, 2014-05-28 23:56:14]

This CL appears to have broken the darwin-386-cheney builder. See http://build.golang.org/log/006cd9eed21c968b522602c7d9f09d0eeb626323

[r, 2014-05-29 00:09:08]

The breakage looks real and 386-specific On Wed, May 28, 2014 at 4:56 PM, <gobot@golang.org> wrote: > This CL appears to have broken the darwin-386-cheney builder. > See http://build.golang.org/log/006cd9eed21c968b522602c7d9f09d0eeb626323 > > https://codereview.appspot.com/102820043/ 

[rsc, 2014-05-29 00:12:35]

Looking... 

[rsc, 2014-05-29 01:43:45]

It's a complete mystery. I'll roll this back and try again in the morning.