search for: gccgo

Hi! gccgo now trips the assertion in Constants.cpp, line 1318: assert(!HAS_RTL_P(exp) && "Cache collision with decl_llvm!"); Does it make sense to split WeakVHCache (Cache.cpp) into ConstantCache and DeclCache? Thanks! -- Sanjoy Das http://playingwithpointers.com

Hi! I've been playing with gccgo / dragonegg, trying to get it to compile Go reliably. One of the problems I am currently facing is that when compiling Go, GCC tends to generate GIMPLE calls that don't have the correct type (or so it seems to me :) ). For instance, when compiling ddd.go from the Go testsuite, I get this:...

...in of the exception (i.e. the > address of the offending load/store). Alternatively, you could insert > runtime checks at the loads/stores, but then it won't be "zero-cost". I'm pretty sure that it is possible to unwind through signal handlers. This is, for example, how gccgo implements some run-time panics. Thanks, -- Peter

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

...parameter). I'll send a revised set of patches within sometime this week, addressing all such issues I can find. That apart, about getting Go to work with dragonegg: 1. Does it sound viable? 2. What things do I need to keep in mind? Currently, I'm passing `-fplugin=./dragonegg.so' to gccgo and have edited dragonegg to enable segmented stacks when it detects the language is "GNU Go". This seems to do what I expect (saving the fact the binaries throw a mysterious SIGILL :) ). Thanks! -- Sanjoy Das http://playingwithpointers.com

...e at link time. This may be beneficial for C/C++ compilation as it may allow us to parallelize/deduplicate the code generation work for at least some functions. Thanks, -- Peter [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140630/224359.html [2] http://golang.org/doc/install/gccgo#Imports

...> want to chime in on how this might interact with ELF or COFF. > > - Daniel I don't know of any ELF implementation that currently supports this in general, but adding it should't be too hard. Go does automatic linking, but it now has its own object file format that handles it. gccgo for ELF seems to produce .go_export sections and <package>..import symbols which are both specific to Go. - Michael Spencer

On 08/10/2011 11:03 AM, Sanjoy Das wrote: > Hi! > > Attached my pre-midterm GSoC work for segmented stacks for review (with > the required fixes). Nice work! + extern bool EnableSegmentedStacks; Can you add a comment like the other declarations? I think the patch looks good. There are possible improvements, but the patch is already in an state where it can be tested and extended

On Tue, Aug 16, 2011 at 09:06:52AM +0200, Duncan Sands wrote: > thanks for working on this! As far as I know, split stacks are the only thing > special to GCC Go, otherwise the generic GCC infrastructure was enough. Not true. At least on x86_64, Go uses a different calling convention. Joerg

No, its up to them which backend they want to use. Sounds like they think that GCC is super quick compared to LLVM. Looks like another fud fart out of google to me. 2009/11/12 Jon McLachlan <mclachlan at apple.com>: > Any plans to make LLVM work with Google's new language, Go? > >

...M is slow is correct: it's definitely slower than a non-optimizing compiler. They then later implemented an optimizing implementation, which they based on GCC because they had a team member (Ian) who is a GCC expert. On the positive side, Ian seemed very positive and even encouraging that his GCCGo frontend might be retargettable from GCC to LLVM, so I wouldn't rule it out as a possibility if some interested community members stepped up to do it. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

Any plans to make LLVM work with Google's new language, Go? http://www.technewsworld.com/story/Go-Go-Google-Programming-Language-68622.html?wlc=1257974768&wlc=1258041607&wlc=1258047741

On Tue, Apr 01, 2014 at 09:03:10PM +0100, David Chisnall wrote: > On 1 Apr 2014, at 19:38, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > I'm pretty sure that it is possible to unwind through signal handlers. This > > is, for example, how gccgo implements some run-time panics. > > It' highly OS dependent and not something to rely on for any > vaguely-portable code. libc++abi's unwind doesn't really support unwinding through signal handlers, at least it wouldn't do anything special for them. I don't have the...

...et of patches within sometime this > week, addressing all such issues I can find. > > That apart, about getting Go to work with dragonegg: > > 1. Does it sound viable? > 2. What things do I need to keep in mind? > > Currently, I'm passing `-fplugin=./dragonegg.so' to gccgo and have > edited dragonegg to enable segmented stacks when it detects the > language is "GNU Go". This seems to do what I expect (saving the fact > the binaries throw a mysterious SIGILL :) ). thanks for working on this! As far as I know, split stacks are the only thing specia...

Hi! Attached my pre-midterm GSoC work for segmented stacks for review (with the required fixes). Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-command-line-option-to-enable-segmented-stacks.patch Type: text/x-diff Size: 1699 bytes Desc: not available URL:

Hi all, We plan to add some auto-linking support for Mach-O, and need a scheme for encoding this information in the LLVM IR. We would like the same scheme to be able to support Microsoft's #pragma comment(lib,...) and #pragma comment(library, ...) features eventually. The current proposal is as follows: -- #1. Extend module-level metadata flags (llvm.module.flags) to support two new

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a

On 9/8/20 11:47 AM, Dan Kortschak wrote: > Thanks, Tomas. > > This is unfortunate. Calling between Go and C is not cheap; the gc > implementation of the Go compiler (as opposed to gccgo) uses different > calling conventions from C and there are checks to ensure that Go > allocated memory pointers do not leak into C code. For this reason I > wanted to avoid these if at all possible (I cannot for allocations > since I don't want to keep tracking changes in how R impl...

On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the

Hello, I am writing an R/Go interoperability tool[1] that work similarly to Rcpp; the tool takes packages written in Go and performs the necessary Go type analysis to wrap the Go code with C and R shims that allow the Go code to then be called from R. The system is largely complete (with the exception of having a clean approach to handling generalised attributes in the easy case[2] - the less