similar to: [LLD] How to get rid of debug info of sections deleted by garbage collector

Thank you all for your time in responding to my query. My understanding was also similar to what you all mentioned here but wanted to check if there are any recent developments in solving this problem. Thanks, Ramana On Thu, Sep 20, 2018 at 9:32 PM, Rui Ueyama <ruiu at google.com> wrote: > Right. Technically we can get rid of debug info that corresponds to dead > sections, but in

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Davide Italiano via llvm-dev > Sent: Thursday, September 20, 2018 10:55 AM > To: ramana.venkat83 at gmail.com; Cary Coutant > Cc: llvm-dev; LLDB > Subject: Re: [llvm-dev] [lldb-dev] [LLD] How to get rid of debug info of > sections deleted by garbage collector > >

Hi all, I have no experience with wireless VoIP. Do you have some quality wireless phones to suggest ? Thanks in advance. Sylvain COUTANT http://www.adviseo.net/

Hi there, When I compile my code with -fdata-sections and -ffunction-sections, I still see some unused string in my shared library (Android). Actually, the strings appear together inside a .rodata.str1.1 section instead of getting their own section. It seems that the C-string literal are considered differently than other constant and the -fdata-sections is not respected in

thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore

Jon Harrop wrote: > If you are familiar with functional programming and, in particular, its > benefits in the context of compiler work then you might like to use Gordon's > OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use > and will make subsequent work vastly easier than trying to write everything > in C++. Or, indeed, the Haskell bindings

thomas weidner wrote: >>The reason why I ask is that I expressed an outrageous opinion at >>Supercomputing back in November, to wit, that CL is probably the best >>language suited for today's multicore problems... but I don't have the >>time to hack one of the current implementations to proove the point. > > > interesting, what makes lisp superior in this

Scott Michel wrote: > thomas weidner wrote: > >>>The reason why I ask is that I expressed an outrageous opinion at >>>Supercomputing back in November, to wit, that CL is probably the best >>>language suited for today's multicore problems... but I don't have the >>>time to hack one of the current implementations to proove the point. >>

On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? In fact, yes! http://code.google.com/p/scarcity/ -Chris

LLVM has GC possibility (llvm_gc_allocate). What compiler uses it? I try ldc D compiler but it not uses LLVM garbage collection but own in Tango library. -- View this message in context: http://old.nabble.com/How-start-with-LLVM-garbage-collector--tp29505874p29505874.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Since you are using a copying collector, may I ask how do you handle registers holding pointers to intermediate values? The example I am considering is something like void foo(void); void f(long long *v, long long n) { long long int i; for (i = 0; i < n; ++i) { v[i] = i; foo(); } } If *v points to gc memory, we can start the function with %v.addr = alloca i64*, align 8

Where's the problem? A pointer to v's alloca escapes to llvm.gcroot, so the optimizers should know that foo could modify the value it holds. foo() might also read v[i] through the escaped pointer, so the store will have to happen before the call. Reid 2011/3/8 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: > Since you are using a copying collector, may I ask how do

Hi all, As part of my bachelor's thesis I'm trying to implement a new LLVM-based back end for the OCaml compiler. Currently I have a problem with LLVM's interface to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0

In my package [1] I open handles to temporary files from c++, pointer to the objects containing those handles are returned to R as external pointer objects. The files are deleted when the corresponding R-object is deleted and the garbage collector runs: a <- lvec(10, "integer") rm(a) Then when the garbage collector runs the file is deleted. However, on some platforms (probably

Basile STARYNKEVITCH wrote: > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is

Jaap Suter wrote: >> LLVM currently lacks working examples demonstrating the use of garbage >> collection... > > Hello, > > if anybody has time, I would recommend putting a big disclaimer at the top of > the garbage collection page that explains that, for the most part, garbage > collection falls outside of LLVM's domain. > > Right now LLVM

Full_Name: Saket Joshi Version: 1.5.0 OS: Solaris 5.8 Submission from: (NULL) (128.193.38.91) According to the documentation obtained by entering: help.search("gc"), the command gc() forces garbage collection and gives the memory usage statistics along with the trigger values in bytes also interpretted in megabytes. However when I ran gc(), the result was a list giving the memory usage

On Tuesday 05 February 2008 12:40:20 thomas weidner wrote: > I wanted to roll out my own lisp, and maybe use some library code from > existing lisps (think of loop or format). Adding an LLVM backend to an > existing lisp implementation is a nice idea, but currently not planned. I am also interested in implementing functional programming languages using LLVM. Although I'm only

On Tuesday 05 February 2008 17:22:36 Jaap Suter wrote: > if anybody has time, I would recommend putting a big disclaimer at the top > of the garbage collection page that explains that, for the most part, > garbage collection falls outside of LLVM's domain. Yes. However, I think it would also be extremely productive to have working examples showcasing what LLVM does provide, e.g.

In R 3.5 and later you should not need to gc() -- that should happen automatically within the connections code. Nevertheless, I would recommend redesigning your approach to avoid hanging onto open file connections as these are a scarce resource. You can keep around your temporary files without having them open and only open/close them on access, with the close run in an on.exit or a