similar to: [LLVMdev] Proposal: add Go frontend subproject based on llgo

On Tue Nov 25 2014 at 18:30:08 Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > Just curious: are you considering the possibility of enabling LTO across > user and runtime code? > Since AFAIK the product of go build is almost always a statically-linked > executable, I guess it would make sense (when doing an optimised build) to > feed the runtime to the linker in IR

On Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote: > > llgo depends on certain third-party components, namely a copy of the Go > > standard library (libgo), a Go program analysis library (go.tools) and two > > library dependencies of the standard library (libbacktrace and libffi). >

Hi all, I'd like to propose that we add an official set of Go bindings to the LLVM project. These bindings are based on the existing "gollvm" project [1]. (Note that all contributors to the gollvm project have agreed to relicense their changes under the LLVM license and submit them to the LLVM project.) The bindings would live in the LLVM tree under the bindings/go directory. One

Martin, good to hear from you. Thanks for the effort - I will test on 32bit and 64bit Windows 10. I will report ASAP. Ivan On Sun, Aug 16, 2020 at 8:42 PM Martin Storsjö <martin at martin.st> wrote: > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > > > > > On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > > Hi, > >

> Which projects do we put under this monolithic repository? The proposal at the moment is to include llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt, openmp, and parallel-libs. This is the set {llvm} plus the transitive closure of "projects that are version-locked to a project in the set", where the closure is taken over the set of all active LLVM

This has already been discussed extensively in the public. The threads are available in the archives. -Chris > On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Sorry, but I really don't think a private conversation is appropriate > for such discussions. > > If the motive cannot be explained in public I have no choice

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > I can find old threads about it, but nothing saying why it was decided > that contributor agreement wouldn't work. Care to send the URL? Here are some quick points that come to mind: 1. It raises the bar to contribution, because something must be “signed” before a

Hi all, Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is

Hi Rafael, We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk. -Chris > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Hi, > > I still don't see any justification in the text why a license change is >

Hi, I'm confused about my licensing obligation with respect to the Xapian SWIG bindings. I've got a python wrapper that sits above the standard Xapian Python/SWIG bindings, and I wasn't sure if the *intent* of the Xapian team is that my python wrapper - and any code that also uses my wrapper also falls under GPLv2. It seems unclear if the FSF's position on dynamic linking in

> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote: >> The goals of this effort are outlined in the previous email but, in short, we aim to: >> - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors.

Hello, I would like to see Xapian used more widely in the PHP community. The major obstacle is that binaries of the PHP extension cannot be distributed. I've been reading earlier discussions on this and wonder if there's now an option. My starting points were https://trac.xapian.org/wiki/FAQ/PHP%20Bindings%20Package and the discussion at https://trac.xapian.org/ticket/191. One comment

"The llgo frontend has been removed for now, but may be resurrected in the future." Thoughts? -eric On Tue, Aug 25, 2020 at 2:18 PM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone add a mention about the llgo removal to the release notes? > > Thanks, > Hans > > On Fri, Feb 14, 2020 at 3:40 PM James Y Knight via llvm-dev >

Hi Everyone, I’d like to start a discussion about how to improve some important issues we have in the LLVM community, regarding our license and patent policy. Before we get started, I’d like to emphasize that *this is an RFC*, intended for discussion. There is no time pressure to do something fast here -- we want to do the right long-term thing for the community (though we also don’t want

Hi all, the monorepo contains a Go frontend called 'llgo' (in the llgo/ top level folder). It apparently hasn't been active since 2017 and before that it wasn't very active either (there were 13 commits in 2016 apparently, most of it minor fixes). I would propose that we remove it from the monorepo for the following reasons: * It is apparently unmaintained. * It only supports a

Nope, it wasn't all reverted -- the llgo implementation remains deleted. There's been some confusion borne out of unfortunate naming -- only the file "llvm/tools/llvm-go/llvm-go.go" was reinstated. Despite its confusing name, this tool is *not* a go implementation, and has effectively nothing to do with llgo. It's only a tiny utility script used by the llvm build process for

On Wed, Jul 20, 2016 at 5:02 PM, Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> writes: > > I would like to (re-)open a discussion on the following specific > question: > > > > Assuming we are moving the llvm project to git, should we > > a) use multiple git repositories, linked

Yep - delete it. If someone wants it back they can resurrect it from version control & explain why it's worth adding back in. On Mon, Feb 10, 2020 at 9:17 AM Jonas Devlieghere via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for bringing this up! Strong +1 from me for all the reasons > you've mentioned. > > On Mon, Feb 10, 2020 at 8:42 AM Raphael Isemann

On Wed, Jul 20, 2016 at 5:02 PM Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> writes: > > I would like to (re-)open a discussion on the following specific > question: > > > > Assuming we are moving the llvm project to git, should we > > a) use multiple git repositories, linked

Sure, that's fine with me. Peter On Mon, Feb 10, 2020 at 9:57 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Calling pcc real fast :) > > -eric > > On Mon, Feb 10, 2020 at 9:49 AM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Yep - delete it. If someone wants it back they can resurrect it from >>