Compiler changes:
* Change map assignment to use mapassign and assign value directly.
* Change string iteration to use decoderune, faster for ASCII strings.
* Change makeslice to take int, and use makeslice64 for larger values.
* Add new noverflow field to hmap struct used for maps.
Unresolved problems, to be fixed later:
* Commented out test in go/types/sizes_test.go that doesn't compile.
* Commented out reflect.TestStructOf test for padding after zero-sized field.
Reviewed-on: https://go-review.googlesource.com/35231
gotools/:
Updates for Go 1.8rc1.
* Makefile.am (go_cmd_go_files): Add bug.go.
(s-zdefaultcc): Write defaultPkgConfig.
* Makefile.in: Rebuild.
From-SVN: r244456
The gc library allocates a _panic struct on the stack. This does not
work for gccgo, because when a deferred function recovers the panic we
unwind the stack up to that point so that returning from the function
will work correctly.
Allocating on the stack fine if the panic is not recovered, and it
works fine if the panic is recovered by a function that
returns. However, it fails if the panic is recovered by a function
that itself panics, and if that second panic is then recovered by a
function higher up on the stack. When we unwind the stack to that
second panic, the g will wind up pointing at a panic farther down on
the stack. Even then everything will often work fine, except when the
deferred function catching the second panic makes a bunch of calls
that use stack space before returning. In that case the code can
overwrite the panic struct, which will then cause disaster when we
remove the struct from the linked list, as the link field will be
garbage. This case is rare enough that all the x86 tests were passing,
but there was a failure on ppc64le.
Before https://golang.org/cl/33414 we allocated the panic struct on
the heap, so go back to doing that again.
Fixesgolang/go#18228.
Reviewed-on: https://go-review.googlesource.com/34027
From-SVN: r243444
With -buildmode=c-archive, initsig is called before the memory
allocator has been initialized. The code was doing a memory
allocation because of the call to funcPC(sigtramp). When escape
analysis is fully implemented, that call should not allocate. For
now, finesse the issue by calling a C function to get the C function
pointer value of sigtramp.
When returning from a call from C to a Go function, a deferred
function is run to go back to syscall mode. When the call occurs on a
non-Go thread, that call sets g to nil, making it impossible to add
the _defer struct back to the pool. Just drop it and let the garbage
collector clean it up.
Reviewed-on: https://go-review.googlesource.com/33675
From-SVN: r242992
The actual stack unwind code is still in C, but the rest of the code,
notably all the memory allocation, is now in Go. The names are changed
to the names used in the Go 1.7 runtime, but the code is necessarily
somewhat different.
The __go_makefunc_can_recover function is dropped, as the uses of it
were removed in https://golang.org/cl/198770044.
Reviewed-on: https://go-review.googlesource.com/33414
From-SVN: r242715
Add a little shell script to auto-generate runtime.sigtable from the
known signal names.
Force the main package to always import the runtime package. Otherwise
some runtime package global variables may never be initialized.
Set the syscallsp and syscallpc fields of g when entering a syscall, so
that the runtime package knows when a g is executing a syscall.
Fix runtime.funcPC to avoid dead store elimination of the interface
value when the function is inlined.
Reviewed-on: https://go-review.googlesource.com/33025
From-SVN: r242060
This upgrades all of libgo other than the runtime package to
the Go 1.4 release. In Go 1.4 much of the runtime was
rewritten into Go. Merging that code will take more time and
will not change the API, so I'm putting it off for now.
There are a few runtime changes anyhow, to accomodate other
packages that rely on minor modifications to the runtime
support.
The compiler changes slightly to add a one-bit flag to each
type descriptor kind that is stored directly in an interface,
which for gccgo is currently only pointer types. Another
one-bit flag (gcprog) is reserved because it is used by the gc
compiler, but gccgo does not currently use it.
There is another error check in the compiler since I ran
across it during testing.
gotools/:
* Makefile.am (go_cmd_go_files): Sort entries. Add generate.go.
* Makefile.in: Rebuild.
From-SVN: r219627
Ian Lance Taylor