]> git.ipfire.org Git - thirdparty/gcc.git/commit - gcc/go/gofrontend/expressions.cc
compiler, runtime: harmonize types referenced by both C and Go
authorian <ian@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 15 Feb 2019 01:57:51 +0000 (01:57 +0000)
committerian <ian@138bc75d-0d04-0410-961f-82ee72b054a4>
Fri, 15 Feb 2019 01:57:51 +0000 (01:57 +0000)
commit81487fff93c77bef51d16a992b49426d42329a3c
tree0722c462bd08d8478a0d1861b10b9f966193505e
parent600bc9f1202dba21ff5c6624f0b634920216079f
compiler, runtime: harmonize types referenced by both C and Go

    Compiling with LTO revealed a number of cases in the runtime and
    standard library where C and Go disagreed about the type of an object or
    function (or where Go and code generated by the compiler disagreed). In
    all cases the underlying representation was the same (e.g., uintptr vs.
    void*), so this wasn't causing actual problems, but it did result in a
    number of annoying warnings when compiling with LTO.

    Reviewed-on: https://go-review.googlesource.com/c/160700

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268923 138bc75d-0d04-0410-961f-82ee72b054a4
21 files changed:
gcc/go/gofrontend/MERGE
gcc/go/gofrontend/expressions.cc
gcc/go/gofrontend/gogo.cc
gcc/go/gofrontend/runtime.cc
gcc/go/gofrontend/runtime.def
gcc/go/gofrontend/wb.cc
libgo/go/runtime/mgc.go
libgo/go/runtime/netpoll.go
libgo/go/runtime/proc.go
libgo/go/runtime/stubs.go
libgo/go/syscall/syscall_unix.go
libgo/go/syscall/wait.c
libgo/runtime/go-caller.c
libgo/runtime/go-callers.c
libgo/runtime/go-libmain.c
libgo/runtime/go-main.c
libgo/runtime/go-reflect-call.c
libgo/runtime/go-varargs.c
libgo/runtime/panic.c
libgo/runtime/runtime.h
libgo/runtime/stack.c