Skip to content

G
golang
Switch branch/tag
  1. 02 Feb, 2018 1 commit
  3. 31 Jan, 2018 10 commits
  5. 30 Jan, 2018 7 commits
  7. 29 Jan, 2018 2 commits
  9. 28 Jan, 2018 1 commit
  11. 26 Jan, 2018 2 commits
  13. 25 Jan, 2018 5 commits
  15. 24 Jan, 2018 5 commits
  17. 23 Jan, 2018 7 commits
    • Keith Randall's avatar
      cmd/compile: don't let spills clobber arguments · 7eaa8efb
      Keith Randall authored 
      The compiler allows code to have multiple differently-typed views of a
single argument. For instance, if we have

func f(x float64) {
   y := *(*int64)(unsafe.Pointer(&x))
   ...
}

Then in SSA we get two OpArg ops, one with float64 type and one with
int64 type.

The compiler will try to reuse argument slots for spill slots. It
checks that the argument slot is dead by consulting an interference
graph.

When building the interference graph, we normally ignore cross-type
edges because the values on either end of that edge can't be allocated
to the same slot. (This is just a space-saving optimization.) This
rule breaks down when one of the values is an argument, because of the
multiple views described above. If we're spilling a float64, it is not
enough that the float64 version of x is dead; the int64 version of x
has to be dead also.

Remove the optimization of not recording interference edges if types
don't match. That optimization is incorrect if one of the values
connected by the edge is an argument.

Fixes #23522

Change-Id: I361f85d80fe3bc7249014ca2c3ec887c3dc30271
Reviewed-on: https://go-review.googlesource.com/89335
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      7eaa8efb
    • Robert Griesemer's avatar
      go/types: more robust behavior in the presence errors (due to import "C") · f27a1ff2
      Robert Griesemer authored 
      - Don't complain about invalid constant type if the type is
  invalid already (we do this in other places as well). This
  is useful to do in general, and even more so if we have
  invalid types due to import "C".

- Type-check the lhs of an assignment even if we bail out early
  due to an error on the rhs. This was simply an oversight. We
  already have machinery in place to "use" expressions; in this
  case we just have to also make sure we don't overcount "uses"
  of variables on the lhs.

- Fix overcount uses correction in assignments: Only do it if
  the variable in question is declared inside the same package
  to avoid possible race conditions when type-checking exported
  variables concurrently.

Fixes #22090.

Change-Id: I4c1b59f9ce38970e7129fedc5f6023908386e4f1
Reviewed-on: https://go-review.googlesource.com/88375Reviewed-by: 's avatarAlan Donovan <adonovan@google.com>
      f27a1ff2
    • Austin Clements's avatar
      runtime: never allocate during an unrecoverable panic · 2edc4d46
      Austin Clements authored 
      Currently, startpanic_m (which prepares for an unrecoverable panic)
goes out of its way to make it possible to allocate during panic
handling by allocating an mcache if there isn't one.

However, this is both potentially dangerous and unnecessary.
Allocating an mcache is a generally complex thing to do in an already
precarious situation. Specifically, it requires obtaining the heap
lock, and there's evidence that this may be able to deadlock (#23360).
However, it's also unnecessary because we never allocate from the
unrecoverable panic path.

This didn't use to be the case. The call to allocmcache was introduced
long ago, in CL 7388043, where it was in preparation for separating Ms
and Ps and potentially running an M without an mcache. At the time,
after calling startpanic, the runtime could call String and Error
methods on panicked values, which could do anything including
allocating. That was generally unsafe even at the time, and CL 19792
fixed this be pre-printing panic messages before calling startpanic.
As a result, we now no longer allocate after calling startpanic.

This CL not only removes the allocmcache call, but goes a step further
to explicitly disallow any allocation during unrecoverable panic
handling, even in situations where it might be safe. This way, if
panic handling ever does an allocation that would be unsafe in unusual
circumstances, we'll know even if it happens during normal
circumstances.

This would help with debugging #23360, since the deadlock in
allocmcache is currently masking the real failure.

Beyond all.bash, I manually tested this change by adding panics at
various points in early runtime init, signal handling, and the
scheduler to check unusual panic situations.

Change-Id: I85df21e2b4b20c6faf1f13fae266c9339eebc061
Reviewed-on: https://go-review.googlesource.com/88835
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      2edc4d46
    • Austin Clements's avatar
      runtime: don't grow the stack on sigpanic if throwsplit · 9483a0bc
      Austin Clements authored 
      Currently, if a _SigPanic signal arrives in a throwsplit context,
nothing is stopping the runtime from injecting a call to sigpanic that
may attempt to grow the stack. This will fail and, in turn, mask the
real problem.

Fix this by checking for throwsplit in the signal handler itself
before injecting the sigpanic call.

Updates #21431, where this problem is likely masking the real problem.

Change-Id: I64b61ff08e8c4d6f6c0fb01315d7d5e66bf1d3e2
Reviewed-on: https://go-review.googlesource.com/87595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      9483a0bc
    • Robert Griesemer's avatar
      spec: consistently use "defined type" and "type name" (cleanup) · 9b49ac03
      Robert Griesemer authored 
      When we introduced the notion of alias type declarations, we renamed
"named type" to "defined type" to avoid confusion with types denoted
by aliases and thus are also types with names, or "named types".

Some of the old uses of "named types" remained; this change removes
them.

Now the spec consistently uses the terms:

- "defined type"  for a type declared via a type definition
- "type name"     for any name denoting an (alias or defined) type
- "alias"         for a type name declared in an alias declaration

New prose is encouraged to avoid the term "named type" to counter-
act further confusion.

Fixes #23474.

Change-Id: I5fb59f1208baf958da79cf51ed3eb1411cd18e03
Reviewed-on: https://go-review.googlesource.com/89115Reviewed-by: 's avatarRob Pike <r@golang.org>
      9b49ac03
    • fanzha02's avatar
      cmd/internal/obj/arm64: fix assemble VLD1/VST1 bug · cafb36bf
      fanzha02 authored 
      The current code misassembles VLD1/VST1 instruction with non-zero
offset. The offset is dropped silently without any error message.
The cause of the misassembling is the current code treats argument
(Rn)(Rm) as ZOREG type.

The fix changes the matching rules and considers (Rn)(Rm) as ROFF
type. The fix will report error information when assembles VLD1/VST1
(R8)(R13), [V1.16B].
The fix enables the ARM64Errors test.

Fixes #23448

Change-Id: I3dd518b91e9960131ffb8efcb685cb8df84b70eb
Reviewed-on: https://go-review.googlesource.com/87956Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      cafb36bf
    • Russ Cox's avatar
      doc, cmd/go: final release notes edits · 4a2f28f5
      Russ Cox authored 
      Except for removing the DRAFT marker, I think these are now ready to go.

Change-Id: I20604f5b135616189a24990db463c7bb5e7d48f1
Reviewed-on: https://go-review.googlesource.com/88975
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      4a2f28f5