E.g., here's the new "go build" output:
$ go build misc/cgo/errors/issue8442.go
# command-line-arguments
could not determine kind of name for C.issue8442foo
gcc errors for preamble:
misc/cgo/errors/issue8442.go:11:19: error: unknown type name 'UNDEF'
Fixes#8442.
LGTM=iant
R=iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/129160043
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes#8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
Restore https://golang.org/cl/41040043 after GC rewrite.
Original description:
On the plus side, we don't need to change the bits on malloc and free.
On the downside, we need to mark objects in the free lists during GC.
But the free lists are small at GC time, so it should be a net win.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 21.9 20.4 -6.85%
BenchmarkMalloc16 31.1 29.6 -4.82%
LGTM=khr
R=khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/122280043
Basically this cleanup replaces all the usage usages of strcmp() == 0,
found by the following command line:
$ grep -R strcmp cmd/dist | grep "0"
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/123330043
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
This allows implementing address-of-global
as a pc-relative address instead of as a
32-bit integer constant.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/128070045
This allows changing the addressing mode for constant
global addresses to use pc-relative addressing.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/129830043
You talked me into it. This and other links should be updated
once the new import paths for the subrepos are established.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/124260043
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
codeblk and datblk were truncating their
arguments to int32. Don't do that.
LGTM=dvyukov, rminnich
R=iant, dvyukov, rminnich
CC=golang-codereviews
https://golang.org/cl/126050043
See golang.org/s/go14customimport for design.
Added case to deps_test to allow go/build to import regexp.
Not a new dependency, because go/build already imports go/doc
which imports regexp.
Fixes#7453.
LGTM=r
R=r, josharian
CC=golang-codereviews
https://golang.org/cl/124940043
It's unclear why we do this broken double-checked locking.
The mutex is not held for the whole duration of CPU profiling.
Fixes#8365.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116290043
This function does not have a declaration/prototype in a.h, and it is used only
in buf.c, so it is local to it and thus can be marked as private by adding
'static' to it.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/122300043
misc/cgo/testgodefs was added by revision d1cf884a594f, but not
add to run.bash.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/129760044
This makes GCC behavior (and cgo build failures) deterministic.
Fixes#8487.
Ran this shell command on linux/amd64 (Ubuntu 12.04) before and
after this change:
for x in `seq 100`; do
go tool cgo -debug-gcc=true issue8441.go 2>&1 | md5sum
done | sort | uniq -c
Before:
67 2cdcb8c7c4e290f7d9009abc581b83dd -
10 9a55390df94f7cec6d810f3e20590789 -
10 acfad22140d43d9b9517bbc5dfc3c0df -
13 c337f8fee2304b3a8e3158a4362d8698 -
After:
100 785c316cbcbcd50896695050e2fa23c1 -
LGTM=minux, iant
R=golang-codereviews, bradfitz, minux, iant
CC=golang-codereviews
https://golang.org/cl/126990043
Credit to Rémy for finding and writing test case.
Fixes#8325.
LGTM=r
R=golang-codereviews, r
CC=dave, golang-codereviews, iant, remyoudompheng
https://golang.org/cl/124950043
The >>1 shift needs to happen before converting to int32, otherwise
large values will decode with an incorrect sign bit.
The <<31 shift can happen before or after, but before is consistent
with liblink and the go12symtab doc.
Bug demo at http://play.golang.org/p/jLrhPUakIu
LGTM=rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/119630043
When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.
Fixes#8497.
LGTM=r
R=golang-codereviews, iant, gobot, r
CC=golang-codereviews
https://golang.org/cl/126840043
On OS X 10.10 Yosemite, if you have a directory that can be returned
in a single getdirentries64 call (for example, a directory with one file),
and you read from the directory at EOF twice, you get EOF both times:
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
getdirentries64(fd) returns 0 (EOF)
But if you remove the file in the middle between the two calls, the
second call returns an error instead.
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
remove("dir/file")
getdirentries64(fd) returns ENOENT/EINVAL
Whether you get ENOENT or EINVAL depends on exactly what was
in the directory. It is deterministic, just data-dependent.
This only happens in small directories. A directory containing more data
than fits in a 4k getdirentries64 call will return EOF correctly.
(It's not clear if the criteria is that the directory be split across multiple
getdirentries64 calls or that it be split across multiple file system blocks.)
We could change package os to avoid the second read at EOF,
and maybe we should, but that's a bit involved.
For now, treat the EINVAL/ENOENT as EOF.
With this CL, all.bash passes on my MacBook Air running
OS X 10.10 (14A299l) and Xcode 6 beta 5 (6A279r).
I tried filing an issue with Apple using "Feedback Assistant", but it was
unable to send the report and lost it.
C program reproducing the issue, also at http://swtch.com/~rsc/readdirbug.c:
#include <stdio.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
static void test(int);
int
main(void)
{
int fd, n;
DIR *dir;
struct dirent *dp;
struct stat st;
char buf[10000];
long basep;
int saw;
if(stat("/tmp/readdirbug", &st) >= 0) {
fprintf(stderr, "please rm -r /tmp/readdirbug and run again\n");
exit(1);
}
fprintf(stderr, "mkdir /tmp/readdirbug\n");
if(mkdir("/tmp/readdirbug", 0777) < 0) {
perror("mkdir /tmp/readdirbug");
exit(1);
}
fprintf(stderr, "create /tmp/readdirbug/file1\n");
if((fd = creat("/tmp/readdirbug/file1", 0666)) < 0) {
perror("create /tmp/readdirbug/file1");
exit(1);
}
close(fd);
test(0);
test(1);
fprintf(stderr, "ok - everything worked\n");
}
static void
test(int doremove)
{
DIR *dir;
struct dirent *dp;
int numeof;
fprintf(stderr, "\n");
fprintf(stderr, "opendir /tmp/readdirbug\n");
dir = opendir("/tmp/readdirbug");
if(dir == 0) {
perror("open /tmp/readdirbug");
exit(1);
}
numeof = 0;
for(;;) {
errno = 0;
dp = readdir(dir);
if(dp != 0) {
fprintf(stderr, "readdir: found %s\n", dp->d_name);
continue;
}
if(errno != 0) {
perror("readdir");
exit(1);
}
fprintf(stderr, "readdir: EOF\n");
if(++numeof == 3)
break;
if(doremove) {
fprintf(stderr, "rm /tmp/readdirbug/file1\n");
if(remove("/tmp/readdirbug/file1") < 0) {
perror("remove");
exit(1);
}
}
}
fprintf(stderr, "closedir\n");
closedir(dir);
}
Fixes#8423.
LGTM=bradfitz, r
R=golang-codereviews, bradfitz, dsymonds, dave, r
CC=golang-codereviews, iant
https://golang.org/cl/119530044
Current version of Getwd calls Stat that
calls Getwd therefore infinite recursion.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/119600043
