mirror of https://github.com/golang/go.git
e530d6a1e0
Without an explicit signal for a truncation, copy propagation will sometimes propagate a 32-bit truncation and end up overwriting uses of the original 64-bit value. The case that arose in practice is in C but I believe that the same could plausibly happen in Go. The main reason we didn't run into the same in Go is that I (perhaps incorrectly?) drop MOVL AX, AX during gins, so the truncation was never generated, so it didn't confuse the optimizer. Fixes #1315. Fixes #3488. R=ken2 CC=golang-dev https://golang.org/cl/6002043 |
||
|---|---|---|
| .. | ||
| Makefile | ||
| cgen.c | ||
| div.c | ||
| doc.go | ||
| gc.h | ||
| list.c | ||
| machcap.c | ||
| mul.c | ||
| peep.c | ||
| reg.c | ||
| sgen.c | ||
| swt.c | ||
| txt.c | ||