cmd/gc: inline copy in frontend to call memmove directly.
A new node type OSPTR is added to refer to the data pointer of
strings and slices in a simple way during walk(). It will be
useful for future work on simplification of slice arithmetic.
««« original CL description
cmd/5g, cmd/6g, cmd/8g: faster compilation
Replace linked list walk with memset.
This reduces CPU time taken by 'go install -a std' by ~10%.
Before:
real user sys
0m23.561s 0m16.625s 0m5.848s
0m23.766s 0m16.624s 0m5.846s
0m23.742s 0m16.621s 0m5.868s
after:
0m22.714s 0m14.858s 0m6.138s
0m22.644s 0m14.875s 0m6.120s
0m22.604s 0m14.854s 0m6.081s
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13084043
»»»
Asking about runtime/cgo when CgoEnabled=false now correctly
returns an error from build.Import (specifically, NoGoError), because
there are no buildable Go files in that directory.
The API tool was depending on it returning a package with no Go
files instead. Correct that assumption.
Fixes all.bash on local machines.
(Dashboard appears not to be running the api tool at all.)
««« original CL description
cmd/api: break the builds
There is some question about whether the api tool is
running on Windows (see issue 6124), and now I'm
starting to question whether it runs on any of the builders,
since both darwin/amd64 and linux/amd64 are crashing for me
in the api tool due to a recent cgo-related change, and yet
the dashboard is happy.
If the dashboard is still happy after this CL, we have a problem.
There is some question about whether the api tool is
running on Windows (see issue 6124), and now I'm
starting to question whether it runs on any of the builders,
since both darwin/amd64 and linux/amd64 are crashing for me
in the api tool due to a recent cgo-related change, and yet
the dashboard is happy.
If the dashboard is still happy after this CL, we have a problem.
frame is not necessary anymore, but we might some day
get back to functions where the frame size does not vary
by program counter, and if so we'll need it. Avoid needing
to introduce a new struct format later by keeping it now.
go/build: reject directory with only cgo files if cgo not in use
The old test for "no Go files" was p.Name == "", meaning we never
saw a Go package statement. That test fails if there are cgo files
that we parsed (and recorded the package name) but then chose
not to use (because cgo is not available).
Ian Lance Taylor [Wed, 11 Sep 2013 16:01:47 +0000 (09:01 -0700)]
cmd/yacc: replace units example with simpler expr example
The units example is nice but is covered by the Lucent
license, which may be a concern for some people making a
commercial source code distribution of Go.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13283045
The various throwing > 0 finish a change started
in a previous CL, which sets throwing = -1 to mean
"don't show the internals". That gets set during the
"all goroutines are asleep - deadlock!" crash, and it
should also be set during any other expected crash
that does not indicate a problem within the runtime.
Most runtime.throw do indicate a problem within the
runtime, however, so we should be able to enumerate
the ones that should be silent. The goroutine sleeping
deadlock is the only one I can think of.
Otherwise, if panic starts running deferred functions,
the code that panicked appears to be calling those
functions directly, which is not the case and can be
confusing.
net: implement TCP connection setup with fast failover
This CL adds minimal support of Happy Eyeballs-like TCP connection
setup to Dialer API. Happy Eyeballs and derivation techniques are
described in the following:
- Happy Eyeballs: Success with Dual-Stack Hosts
http://tools.ietf.org/html/rfc6555
- Analysing Dual Stack Behaviour and IPv6 Quality
http://www.potaroo.net/presentations/2012-04-17-dual-stack-quality.pdf
Usually, the techniques consist of three components below.
- DNS query racers, that run A and AAAA queries in parallel or series
- A short list of destination addresses
- TCP SYN racers, that run IPv4 and IPv6 transport in parallel or series
This CL implements only the latter two. The existing DNS query
component gathers together A and AAAA records in series, so we don't
touch it here. This CL just uses extended resolveInternetAddr and makes
it possible to run multiple Dial racers in parallel.
For example, when the given destination is a DNS name and the name has
multiple address family A and AAAA records, and it happens on the TCP
wildcard network "tcp" with DualStack=true like the following:
cmd/go: report correct directory for 'no version control'
The scan starts at the directory we care about and works
backward to the GOPATH root. The error should say the
original directory name, not the name of the GOPATH root.
The entry for LEAL/LEAQ in these optabs was listed as having
two data bytes in the y array. In fact they had and expect no data
bytes. However, the general loop expects to be able to look at at
least one data byte, to make sure it is not 0x0f. So give them each
a single data byte set to 0 (not 0x0f).
Since the MOV instructions have the largest optab cases, this
requires growing the size of the data array.
Clang found this bug because the general o->op[z] == 0x0f
test was using z == 22, which was out of bounds.
In practice the next byte in memory was probably not 0x0f
so it wasn't truly broken. But might as well be clean.
For example, if an x_test.go file contains a syntax error,
b.test fails with an error message. But it wasn't printing
the same FAIL line that a build failure later would print.
This makes all the test failures that happen (once we
decide to start running tests) consistently say FAIL.
If using other gdb python scripts loaded before Go's gdb-runtime.py
and that have a different init prototype:
Traceback (most recent call last):
File "/usr/lib/go/src/pkg/runtime/runtime-gdb.py", line 446, in <module>
k()
TypeError: __init__() takes exactly 3 arguments (1 given)
The problem is that gdb keeps all python scripts in the same namespace,
so vars() contains them. To avoid that, load helpers one by one.
Richard Eric Gavaletz [Mon, 9 Sep 2013 22:41:36 +0000 (15:41 -0700)]
container/list: unexpected panic if Next/Prev called outside of list.
Before CL 7065067 calling Next on an element returned either the
next/prev element or nil was returned. After the CL if an element
was not part of a list e.Next() and e.Prev() will panic. This CL
returns to the documented behavior, that Next/Prev returns the
next/prev list element or nil.
Bug3486 tried to walk the entire file tree, but other tests might
be creating and removing files in that tree. In particular, package os
creates and removes files in the os directory, and issue 5863
reports failures due to seeing those files appear and then disappear.
Change the test to walk just the test tree, which should not be
changing.
The code in question is trying to print a nice error message
when a Go EABI binary runs on an OABI machine.
Unfortunately, the only way to do that is to use
ARM Thumb instructions, which we otherwise don't use.
There exist ARM EABI machines that do not support Thumb.
We could run on them if not for this OABI check, so disable it.
Rob Pike [Mon, 9 Sep 2013 03:29:08 +0000 (13:29 +1000)]
doc/go1.2.html: first cut
Lay out the doc and write text for the minor changes.
(I left the net ones for someone who understands them better,
or for someone to describe them to me better so I can write them.)
Much still to do.
Delete go1.2.txt so there's only one thing to update.
compress/flate: prevent panic when reinitializing huffmanDecoder with bad input
The huffmanDecoder struct appears to be intented for reuse by calling init a
second time with a second sequence of code lengths. Unfortunately, it can
currently panic if the second sequence of code lengths has a minimum value
greater than 10 due to failure to reinitialize the links table.
This change prevents the panic by resetting the huffmanDecoder struct back to
the struct's zero value at the beginning of the init method if the
huffmanDecoder is being reused (determined by checking if min has been set to a
non-zero value).
runtime: account for all sys memory in MemStats
Currently lots of sys allocations are not accounted in any of XxxSys,
including GC bitmap, spans table, GC roots blocks, GC finalizer blocks,
iface table, netpoll descriptors and more. Up to ~20% can unaccounted.
This change introduces 2 new stats: GCSys and OtherSys for GC metadata
and all other misc allocations, respectively.
Also ensures that all XxxSys indeed sum up to Sys. All sys memory allocation
functions require the stat for accounting, so that it's impossible to miss something.
Also fix updating of mcache_sys/inuse, they were not updated after deallocation.
Marco Hennings [Fri, 6 Sep 2013 20:49:38 +0000 (16:49 -0400)]
archive/tar: fix a case where USTAR-split is not working correctly.
For some long filenames the USTAR-split code does not work
correctly. It is wrongly assumed that the path would not be too long,
but it is.
The user visible result was that a filename was split, but it still
caused an error.
The cause was a wrongly calculated nlen. In addition I noticed that
at this place it is also seems necessary to check if the prefix will
fit in the 155 chars available for the prefix.
cmd/gofmt: sort more, remove some duplicate imports
* Sort imports by import path, then import name, then comment. Currently, gofmt sorts only by import path.
* If two imports have the same import path and import name, and one of them has no comment, remove the import with no comment. (See the discussion at issue 4414.)
This message was helpful for pre-Go 1 users updating to Go 1.
That time is past. Now the message is confusing because it
depends on knowing what pre-Go 1 looked like.
api: update go1.1, except and next.txt with constant values
O_SYNC changes only on linux-arm (and linux-arm-cgo), but
changes to match O_SYNC on linux-{386,amd64} and what Linux
upstream now uses. See discussion and links on
https://golang.org/cl/13261050/
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13575045
Lucio De Re [Fri, 6 Sep 2013 06:15:44 +0000 (16:15 +1000)]
cmd/dist: Plan 9 build needs an additional include path
cmd/cc: bv.c imports libc.h twice
When using the Plan 9 compiler, the invocation
#include <../ld/textflag.h>
works for the toolchain, but not for the MACH library.
Module cmd/cc/bv.c includes libc.h and "cc.h", which in
turn also includes libc.h. In the Plan 9 context, this
causes a number of duplicate definitions.
R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/13303047