search for: otherpath

On Sat, Apr 19, 2008 at 2:16 PM, Chris Lattner <sabre at nondot.org> wrote: > No. The reason we don't allow this is because it violates the CFG. So if I *don't* violate the CFG, would I still need to do something close to "big and nasty"? ; save the address of %otherPath to use later call @llvm.checkpoint(label %otherPath) ; trick the rest of the compiler to think data flows to both paths *from here* br i1 @opaqueButAlwaysTrue, label %normalPath, label %otherPath normalPath: ; do some work.. call void @work() ; rollback and erase any data changes since...

On Apr 19, 2008, at 12:04 PM, Edward Lee wrote: > On Sat, Apr 19, 2008 at 1:27 PM, Chris Lattner <sabre at nondot.org> > wrote: >> On Apr 19, 2008, at 1:30 AM, Edward Lee wrote: >>> It seems like LLVM happily creates function calls that pass in >>> labels >>> but doesn't know how to emit them. >> Yep, this isn't supported. We

...he CFG, would I still need to do something > close to "big and nasty"? It sounds like you're doing something STM like, have you contacted Torvald to see if he has ideas or insight? http://llvm.org/pubs/2008-02-23-TRANSACT-TangerObjBased.html -Chris > ; save the address of %otherPath to use later > call @llvm.checkpoint(label %otherPath) > ; trick the rest of the compiler to think data flows to both paths > *from here* > br i1 @opaqueButAlwaysTrue, label %normalPath, label %otherPath > > normalPath: > ; do some work.. > call void @work() > ; r...

On Sat, Apr 19, 2008 at 1:27 PM, Chris Lattner <sabre at nondot.org> wrote: > On Apr 19, 2008, at 1:30 AM, Edward Lee wrote: > > It seems like LLVM happily creates function calls that pass in labels > > but doesn't know how to emit them. > Yep, this isn't supported. We can't quite enforce it as invalid at > this moment, but don't expect it to work.

...call CI->replaceAllUsesWith(callAsm); Actually, now that I think about it, maybe I shouldn't even bother using an intrinsic and directly use this inline asm. Assuming that the following transformation won't cause basic blocks to be considered dead. %x = call i1 @llvm.myintrinsic(label %otherPath) ; @myintrinsic always returns true br i1 %x, label %mainPath, label %otherPath Hopefully, even if the CFG optimizer finds that mainPath is always taken, because there's a use of %otherPath by @myintrinsic, that path won't be used. Additionally, to the rest of the compiler, data (e.g., %x)...

...unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -s -e -f ${sender} -d ${recipient} with the auth-socket in dovecot.conf all ok and this in ldap-userdb.conf: user_attrs = vdHome=chroot,mailbox=mail=maildir:%$,quota=quota_rule=*:bytes=%$,otherPath=sieve you see, i have the base directory for the chroot for the entire mail system in ldap:vdHome as /home/vmail/domains and the actual location of the mailbox in maildir format in ldap:mailbox so i can have the actual complete path as /(vdHome)/(mailbox) This is running smoolthly, BUT the chroot...

...; -#include <sys/stat.h> -#include <fcntl.h> -#include <unistd.h> - -int main(int argc __attribute__((unused)), char *argv[]) -{ - int childpid, status, fds[2]; - bool parent; - unsigned int i, acks = 0; - struct xs_handle *h; - char *data; - unsigned int len; - const char *path, *otherpath; - - pipe(fds); - childpid = fork(); - if (childpid == -1) - barf_perror("Failed fork"); - parent = (childpid != 0); - - h = xs_daemon_open(); - if (!h) - barf_perror("Could not connect to daemon"); - - if (!xs_watch(h, "/", "token", 0)) - barf_perror(&quo...