similar to: [LLVMdev] More assertion failures on gccgo/dragonegg

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: i.91 = i; D.785 = i.91.__methods; D.786 =

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to

On Tue, Apr 01, 2014 at 11:35:16AM -0500, Krzysztof Parzyszek wrote: > How do you plan to actually create the exception? The runtime library can invoke the unwinder directly (i.e. using _Unwind_RaiseException). > You cannot simply > throw an exception (via "throw" statement) from a signal handler because > the unwinding won't happen properly. To make it work

Hi! I've been working on coroutines for some time, and it seems you were right - it makes much more sense to have regular C (and assembly) code for handling coroutines. For instance, I'd otherwise would have to make an assumption about the threading model the platform has (or assume there are no threads at all, which prevents me from allowing goroutine like ("run parallel till you

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

Hi, Over in [1] we've been discussing adding support in LTO for an object file-based on-disk module format. Rafael suggested that I send a proposal to this list; this is that proposal. As motivation, consider a compiler that needs to store metadata in the LTO object file that may need to be read by future compilation steps, such as the "export data" used by some Go compilers [2].

On Tue, Jan 15, 2013 at 1:17 PM, Daniel Dunbar <daniel at zuster.org> wrote: > 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

On Nov 12, 2009, at 10:25 AM, Edward O'Callaghan wrote: > 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. Actually, after chatting with Ian about it, it's more of a case of the FAQ being poorly worded than them being anti-LLVM. If you read it closely, it says

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 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 >

Hi Sanjoy, > I've been working on coroutines for some time, and it seems you were > right - it makes much more sense to have regular C (and assembly) code > for handling coroutines. For instance, I'd otherwise would have to > make an assumption about the threading model the platform has (or > assume there are no threads at all, which prevents me from allowing > goroutine

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

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

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? > >

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

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:

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

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