Summary:
To support the use of LLVM_EXTERNAL_LLGO_SOURCE_DIR,
with llgo situated in a location other than tools/llgo,
we add the llgo source directory to LLVM_GO_PACKAGES.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D21635
llvm-svn: 276828
Summary:
The check-libgo target runs "make check" in the
libgo package, which can take a long time on
slower machines. To prevent buildbot failures
due to timeout, we can use Ninja's console pool
for this target.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9495
llvm-svn: 264815
Switch gofrontend to using go.googlesource.com, and
update to 81eb6a3f425b2158c67ee32c0cc973a72ce9d6be.
There are various changes required to update to the
go 1.5 runtime:
typemap.go is changed to accommodate the change in representation for equal/hash algorithms, and the removal of the zero value/type.
CMakeLists.txt is updated to add the build tree to the package search path, so internal packages, which are not installed, are found.
various files changes due to removal of __go_new_nopointers; the same change as in D11863, but with NoUnwindAttribute added to the added runtime functions which are called with "callOnly".
minor cleanups in ssa.go while investigating issues with unwinding/panic handling.
Differential Revisision: http://reviews.llvm.org/D15188
llvm-svn: 263536
Summary:
As llgoi is installed, it must be built or the install
target will fail; there is no implicit dependency.
Adding llgoi to "ALL" makes building llgo as part of an
entire LLVM distribution a bit friendlier: you can then
just do the typical "make && make install".
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11291
llvm-svn: 242750
Summary:
libtool_VERSION was changed in gofrontend a while ago,
but CMakeLists.txt in llgo wasn't updated, and so the
install target fails. Not sure how this went unnoticed
for so long.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11118
llvm-svn: 242291
Summary:
This diff adds line-editing to llgoi, by
vendoring and using github.com/peterh/liner.
I have only implemented the basics here;
follow-ups will come later to add persisted
history, and completion,
Reviewers: pcc
Reviewed By: pcc
Subscribers: axw, llvm-commits
Differential Revision: http://reviews.llvm.org/D9811
llvm-svn: 238100
This takes us to Go 1.4. Also includes a couple of changes to the test
suite, both in the runtime package:
- Disable TestSetPanicOnFault. We cannot support this scenario at all,
due to LLVM's lack of non-call exceptions.
- Tweak TestFinalizerType. This test only passes with two GC runs.
Differential Revision: http://reviews.llvm.org/D8828
llvm-svn: 234134
Summary:
The debug metadata we generate is wrong, and is
now causing build failures. This revision disables
the only llvm.dbg.declare calls we make.
(There is also a drive-by fix to CMakeLists.txt,
adding in a missing .go dependency.)
Fixes http://llvm.org/bugs/show_bug.cgi?id=22330
Reviewers: pcc
Reviewed By: pcc
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D7222
llvm-svn: 227403
llgoi is a Go REPL based on llgo irgen and the LLVM JIT. It supports
expressions, statements, most declarations and imports, including binary
imports from the standard library and source imports from $GOPATH.
Differential Revision: http://reviews.llvm.org/D6957
llvm-svn: 226097
This change allows clients to generate IR using "files" received from locations
other than the file system. The regular file parser is moved to a new library,
"driver", which is intended to eventually contain much of the logic from
the existing driver.
Differential Revision: http://reviews.llvm.org/D6794
llvm-svn: 225026
multilib build and installs.
Summary:
This requires introducing a generated header to encapsulate the
LLVM_LIBDIR_SUFFIX value from the build system and push it into the go
code. From there, I've adjusted the gllgo code to systematically use
this rather than a raw "lib". This requires some awkwardness as one of
the flags *must* be "lib"-relative for compatibility with how gccgo
works. For that flag, we use ".." to back up a directory and then go
into the proper lib directory.
Differential Revision: http://reviews.llvm.org/D6795
llvm-svn: 224964
Andrew Wilkins