The libffi library doesn't understand zero-sized objects.
    When we see a zero-sized field in a struct, just skip it when
    converting to the FFI data structures. There is no value to pass in
    any case, so not telling libffi about the field doesn't affect
    anything.
    
    The test case for this is https://golang.org/cl/123316.
    
    Fixes golang/go#26335
    
    Reviewed-on: https://go-review.googlesource.com/123335

From-SVN: r262651

	PR go/86331
    os: check return value as well as error from waitid
    
    https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it
    is possible for syscall.Syscall6 to return a non-zero errno value even
    if no error occurs. That is a problem in general, but this fix will
    let us work around the general problem for the specific case of
    calling waitid.
    
    Reviewed-on: https://go-review.googlesource.com/121595

From-SVN: r262313

    
    glibc 2.28 removes ustat.h and the ustat function entirely, which
    breaks syscall.Ustat.
    
    Updates golang/go#25990
    
    Reviewed-on: https://go-review.googlesource.com/120535

From-SVN: r261896

    
    Port https://golang.org/cl/120375 over to the gofrontend repo so that
    it gets more reliable testing.
    
    Updates golang/go#22472
    
    Reviewed-on: https://go-review.googlesource.com/120395

From-SVN: r261871

    
    Reviewed-on: https://go-review.googlesource.com/118495

From-SVN: r261549

    
    Incorporates cut down versions of https://golang.org/cl/102835 and
    https://golang.org/cl/106256 from the master sources.
    
    This will tell go/build to skip files with those tags.
    
    Reviewed-on: https://go-review.googlesource.com/117996

From-SVN: r261451

    
    Adjust the hash and string fields computed by StructOf to match the
    values that the compiler computes for a struct type with the same
    field names and types.  This makes the reflect code match the
    compiler's Type::hash_for_method and Type::reflection methods.
    
    Fixes golang/go#25284
    
    Reviewed-on: https://go-review.googlesource.com/116515

From-SVN: r261235

    
    Background: since gccgo does not currently merge identical types at link time,
    the reflect function canonicalize() exists to choose a canonical specimen
    for each set of identical types.
    In this way, user code has the guarantee that identical types
    will always compare as ==
    
    Change: arrange reflect functions MapOf(), SliceOf(), StructOf() etc.
    to call canonicalize() on the types they create, before storing the types
    in internal lookup caches and returning them.
    
    This fixes known cases where canonicalize() is needed but was missing.
    Supersedes https://golang.org/cl/112575 and mostly fixes issue 25284.
    
    Updates golang/go#25284
    
    Reviewed-on: https://go-review.googlesource.com/115577

From-SVN: r261216

    
    Reviewed-on: https://go-review.googlesource.com/115196

From-SVN: r261041

    
    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
    
    cmd/go: don't pass -compiler flag to vet
    
    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.
    
    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
    
    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by
    
    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.
    
    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).
    
    The result is that the cmd/go vet tests pass when using -compiler=gccgo.
    
    Reviewed-on: https://go-review.googlesource.com/114516

From-SVN: r260913

    
    Reviewed-on: https://go-review.googlesource.com/113179

From-SVN: r260908

    
    Several recent changes to the gc version of cmd/go improve the
    gofrontend support. These changes are partially copies of existing
    gofrontend differences, and partially new code. This CL makes the
    gofrontend match the upstream code.
    
    The changes included here come from:
        https://golang.org/cl/111575
        https://golang.org/cl/111595
        https://golang.org/cl/111635
        https://golang.org/cl/111636
    
    For the record, the following recent gc changes are based on code
    already present in the gofrontend repo:
        https://golang.org/cl/110915
        https://golang.org/cl/111615
    
    For the record, a gc change, partially based on earlier gofrontend
    work, also with new gc code, was already copied to gofrontend repo in
    CL 111099:
        https://golang.org/cl/111097
    
    This moves the generated list of standard library packages from
    cmd/go/internal/load to go/build.
    
    Reviewed-on: https://go-review.googlesource.com/112475

gotools/:
	* Makefile.am (check-go-tool): Don't copy zstdpkglist.go.
	* Makefile.in: Rebuild.

From-SVN: r260097

    
    Reviewed-on: https://go-review.googlesource.com/111535

From-SVN: r259946

    
    Update mkalldocs.sh from the current master sources, replacing the old
    mkdoc.sh.
    
    Reviewed-on: https://go-review.googlesource.com/111096

From-SVN: r259920

    
    Since gofrontend does have the vet tool now, we can test it.
    
    Reviewed-on: https://go-review.googlesource.com/111095

From-SVN: r259919

    
    In https://golang.org/cl/111097 the gc version of cmd/go was updated
    to include some gofrontend-specific changes. The gofrontend code
    already has different versions of those changes; this CL makes the
    gofrontend match the upstream code.
    
    Reviewed-on: https://go-review.googlesource.com/111099

From-SVN: r259918

    
    These tests used to be disabled in the gofrontend since the go tool
    didn't support build IDs for the gofrontend. It does now, so enable
    the tests again.
    
    Reviewed-on: https://go-review.googlesource.com/111098

From-SVN: r259875

    
    Reviewed-on: https://go-review.googlesource.com/90775

From-SVN: r259866

    
    We're never going to use stack.go for gccgo.  Although a build tag
    keeps it from being built, even having it around can be confusing.
    Remove it.
    
    Reviewed-on: https://go-review.googlesource.com/40774

From-SVN: r259865

	PR go/85429
    cmd/go: support more Solaris assembler syntaxes
    
    Patch by Rainer Orth.
    
    Reviewed-on: https://go-review.googlesource.com/110563

From-SVN: r259797

	PR go/85429
    cmd/go: add Solaris assembler syntax for gccgo buildid file
    
    The Solaris assembler uses a different syntax for section directives.
    
    This is https://golang.org/cl/109140 ported over to gccgo.
    
    Reviewed-on: https://go-review.googlesource.com/109141

From-SVN: r259719

    
    Bring in https://golang.org/cl/98616 from gc tip.
    
    Original CL description:
    
        This change modifies Go to disable loading of users' shell history for
        TestTerminalSignal tests. TestTerminalSignal, as part of its workload,
        will execute a new interactive bash shell. Bash will attempt to load the
        user's history from the file pointed to by the HISTFILE environment
        variable. For users with large histories that may take up to several
        seconds, pushing the whole test past the 5 second timeout and causing
        it to fail.
    
    Reviewed-on: https://go-review.googlesource.com/107624

From-SVN: r259452

    
    Reviewed-on: https://go-review.googlesource.com/100955

From-SVN: r259445

    
    The gccgo runtime is never stale, and on a system with gc sources in
    ~/go the test may wind up checking whether the gc runtime is stale.
    
    Reviewed-on: https://go-review.googlesource.com/102282

From-SVN: r258865

    
    Tested by installing the gcc-locales package and running
        LANG=de_DE.utf8 go build hello.go
    Without this change, that fails, as described at
    https://gcc.gnu.org/PR84765.
    
    Reviewed-on: https://go-review.googlesource.com/100737

From-SVN: r258565

    
    Reviewed-on: https://go-review.googlesource.com/99117

From-SVN: r258337

    
    Reviewed-on: https://go-review.googlesource.com/97357

From-SVN: r258052

    
    Reviewed-on: https://go-review.googlesource.com/97517

From-SVN: r258051

	PR go/84484
    libgo: add support for riscv64
    
    Patch by Andreas Schwab.
    
    Reviewed-on: https://go-review.googlesource.com/96377

	* go.test/go-test.exp (go-set-goarch): Recognize riscv64-*-*.

From-SVN: r257914

    
    Let a fast syscall return be a preemption point.  This helps with
    tight loops that make system calls, as in BenchmarkSyscallExcessWork.
    
    Reviewed-on: https://go-review.googlesource.com/94895

From-SVN: r257848

    
    In particular this lets BenchmarkPingPongHog in runtime/proc_test.go
    complete.
    
    Reviewed-on: https://go-review.googlesource.com/94735

From-SVN: r257743

    
    Long long long ago Go permitted writing
        func F()
    in one file and writing
        func F() {}
    in another file.  This was removed from the language, and that is now
    considered to be a multiple definition error.  Gccgo never caught up
    to that, and it has been permitting this invalid code for some time.
    
    Stop permitting it, so that we give correct errors.  Since we've
    supported it for a long time, the compiler uses it in a couple of
    cases: it predeclares the hash/equal methods if it decides to create
    them while compiling another function, and it predeclares main.main as
    a mechanism for getting the right warning if a program uses the wrong
    signature for main.  For simplicity, keep those existing uses.
    
    This required a few minor changes in libgo which were relying,
    unnecessarily, on the current behavior.
    
    Reviewed-on: https://go-review.googlesource.com/93083

From-SVN: r257600

	PR go/84215
    runtime, sync/atomic: use write barrier for atomic pointer functions
    
    This copies atomic_pointer.go from 1.10rc2.  It was omitted during the
    transition of the runtime from C to Go, and I forgot about it.
    
    This may help with https://gcc.gnu.org/PR84215.
    
    Reviewed-on: https://go-review.googlesource.com/93197

From-SVN: r257599

    
    If we trace back through code that has no debug info, as when calling
    through C code compiled with -g0, we won't have a function name.
    Try to fetch the function name using the symbol table.
    
    Adding the test case revealed that gotest failed to use the gccgo tag
    when matching files, so add that.
    
    Reviewed-on: https://go-review.googlesource.com/92756

From-SVN: r257495

    
    Reviewed-on: https://go-review.googlesource.com/92736

From-SVN: r257493

    
    The escape analysis support is not yet good enough to avoid escaping
    the argument to funcPC.  This causes unnecessary and often harmful
    memory allocation.  E.g., (*cpuProfile).addExtra can be called from a
    signal handler, and it must not allocate memory.
    
    Move the calls to funcPC to use variables instead.  This was done in
    the original migration to using funcPC, but was not done for newer code.
    
    In one case, in signal handling code, use getSigtramp.
    
    Reviewed-on: https://go-review.googlesource.com/92735

From-SVN: r257463

    
    The offset field in structfield has changed to offsetAnon, and now
    requires a shift to get the actual offset value.
    
    Fixes golang/go#23391
    
    Reviewed-on: https://go-review.googlesource.com/92275

From-SVN: r257413

    
    The quoting code that read _cgo_flags, currently only in the gccgo
    version of cmd/go, was losing the last flag read from the file.
    
    Fixes golang/go#23666
    
    Reviewed-on: https://go-review.googlesource.com/91655

From-SVN: r257373

    
    They were disabled due to the lack of escape analysis. Now that
    we have escape analysis, unskip these tests.
    
    Reviewed-on: https://go-review.googlesource.com/86248

From-SVN: r257324

    
    On ia64, a separate stack is used for saving/restoring register frames,
    occupying the other end of the stack mapping. This must also be scanned
    for pointers into the heap.
    
    Reviewed-on: https://go-review.googlesource.com/85276

From-SVN: r257323