similar to: [LLVMdev] Linking modules across contexts crashes

> On 2015-Jun-01, at 11:06, Reid Kleckner <rnk at google.com> wrote: > > I'm pretty sure module linking is expected to occur in the same LLVM context. Correct. > IIRC Duncan had some proposal for how ld64 could do something clever with multiple contexts, but I've totally forgotten what it was. This was for LTO (probably unrelated to Yuri's scenario?). 1.

Hi, I'm Ryo Ota. I have two questions about `llvm::LLVMContext`. Q1) What is the difference between the following (A)`my_context` and (B)`global_context`? Do I have to create a LLVMContext by myself? Or use `getGlobalContext()`? Could you tell me what situation needs a LLVMContext which is created by myself such as (A)? (A) { llvm::LLVMContext my_context; // codes using only my_context (get

I want to start out with an apache class that will disable all modules except for a pre-defined list, thus establishing a baseline of active modules. Then as needed, other classes could enable a module that they require that would have been disabled by the baseline state. Its possible several classes may try to enable the same module (1 or more classes needing module1 could be on a single node)

In rsyncd.conf I'd like to be able to specify something like: [module1] gateway 10.168.172.9 or (I think we have to change the protocol a little for this one): [module2] redirect datasource.my.domain I've run into this need a few times, and I think it might be useful enough to add (both of these) to the daemon configuration. I'm asking the list to see if either of these might

Hello openssh@ I thought about sftp's reget/reput commands. Several days ago, Damien Miller write to tech at openbsd.org (it was reply for my letter): > Herein lies a problem which is not easy to detect or solve. For > performance reasons, the sftp client does pipelined reads/writes when > transferring files. The protocol spec allows for a server to process > these requests out

Just ran into this bug when running the latest snapshot from CVS: when rsyncing from two source directories into a third one, rsync gets confused about which source file is from which directory, resulting in a "file vanished" error. See test script below. Also, is there any consensus on whether using multiple source modules when pulling from an rsync daemon is going to be ok? I

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

Hi, few months ago I started a thread about running PWGL under wine. PWGL is a " free cross-platform visual language based on Common Lisp, CLOS and OpenGL, specialized in computer aided composition and sound synthesis. " http://www2.siba.fi/PWGL/index.html However, because I had to use winetricks to install Microsoft Visual C++ 2005 (it's needed by PWGL), and the many errors that I

On 08/08/2013 11:04 AM, David Chisnall wrote: > What happens when I link together two IR modules from different front ends that have different language-specific address spaces? I agree with Micah: if during the linking two IR modules there are incoherences (e.g. in module1 2 -> 1 and in module2 2 -> 3) then the modules are incompatible and the link process should fail. > I would be

On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > 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

Yep I tried those two options, and nothing... Even if the pre-user conf files have a log file in the same directory, which I touch before trying, messages keep going to syslog... I tried with 666 permissions on rsyncd.log too just to make sure... The following is one of the user's conf file, hope theres a clue. Thanks! log file = /home/pluto/rsyncd.log <<< This is the problem!!

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

Please, help me understand if 'use chroot' option in daemon config is secure enough. Rsync manual has following lines: As an additional safety feature, you can specify a dot-dir in the module's "path" to indicate the point where the chroot should occur.  This allows rsync to run in a chroot with a non-"/" path for the top of the transfer

Greetings. I am running rsync 2.6.2 on both the server and the client. Server is Fedora Core 2 and client is Red Hat Linux 9. I am suffuring of the following errors on the server side: Jun 7 19:43:27 tux101 rsyncd[24906]: file has vanished: "redhat/9/en/os/i386/RedHat/RPMS/gtk2-engines-2.2.0-2.i386.rpm" (in module1) This messages repeats for a whole bunch of rpm files

LLVM (2.7 release version) provides 2 implementations for inlining function callsites: - InlineSimple.cpp (-inline): inline simple callsites according to its cost analysis - InlineAlways.cpp (-always-inline): inline all callsites that are marked with "always_inline" attribute. They are both subclasses of Inline.cpp that assumes the function's definition (body) is

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_graph.c | 571 ++++++++++++++++++++++++++++++++-- 1 files changed, 538 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_graph.c b/drivers/gpu/drm/nouveau/nv04_graph.c index d96c351..1b0af3a 100644 --- a/drivers/gpu/drm/nouveau/nv04_graph.c +++

Hi, We are using pxelinux at my company to test our product. And there are limitations that we have hit in the past w.r.t. the max length of a path, or the max length of a module name (in mboot.c / mboot.c32). We've used workarounds in the past, and reorganized the directory structure, but we face that problem again. Out of the 128 / FILENAME_MAX chars that can be used, 110 - 120 go to the

On Tue, Jul 27, 2010 at 7:46 AM, Chuck Zhao <czhao at eecg.toronto.edu> wrote: >  LLVM (2.7 release version) provides 2 implementations for inlining > function callsites: > > - InlineSimple.cpp (-inline):               inline simple callsites > according to its cost analysis > - InlineAlways.cpp (-always-inline):  inline all callsites that are > marked with

Why should SelectionDAGBuilder generate an explicit bitcast for a no-op bitcast? By definition, no bits are changed; so if the EVTs match, there is nothing to do. The fundamental problem is how address spaces are handled, and specifically how they are converted, in LLVM IR. Address space casts are currently implemented with bitcasts (in general). While this works out for the LLVM IR type