search for: bolingbrok

Hi! I've been tearing my hair out trying to get DOS file attributes to work with Samba. Basically, I have it all set up so the user mbolingbroke (me) can write to this Supernova Backup share I have - this all works fine. However, since this is going to backup my Windows machine I want to preserve the file attributes. To this end, I've set up mapping of the attributess using "map archive = yes" and so on. However, whenever...

...options that would let me turn this on, and I can see how it would make sense with the old "map * = yes" approach to DOS attributes, but with extended attributes such as I am using surely folders can have DOS attributes too? If anyone could enlighten me I would be most grateful! Max Bolingbroke

...by "Chad Thunberg" <chadth@atvideo.com> > 12) Re: Virus Scanner > by Christian Perrier <perrier@onera.fr> > 13) Re: password change problem > by Todd Pfaff <todd@edge.cis.McMaster.CA> > 14) Compile error 2.0.0beta1 > by "Karl Bolingbroke" <karl.bolingbroke@flyingj.com> > 15) samba 2.0 beta and shadow passwords > by Michael <michael@bizsystems.com> > > ---------------------------------------------------------------------- > > Date: Fri, 20 Nov 1998 09:58:53 +0100 (CET) > From: "k....

...tps://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend). > > They intend to ship GHC with its own local LLVM build. > > This post brings up an interesting point: > > > However, the framework is modular - we can extend LLVM with plugins. For > example, several years ago, Max Bolingbroke ​wrote a plugin for LLVM's > alias analysis that improved the generated code in some cases by 12%, just > by teaching it GHC-specific code generation needs. > > > > However, due to lack of API guarantees mentioned above, it becomes > difficult to support such analysis for...

LLVM Weekly - #43, Oct 27th 2014 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/43>. Welcome to the forty-third issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

...entium 90. It is running RedHat 5.2. The Linux kernel is version 2.0.36. The gcc package is 2.7.2.3-14. Can anyone help me with this? My background is primarily networking, so the C error messages don't mean much to me. Thanks for anything you can do. Karl ------------------------ Karl Bolingbroke Flying J Inc. 435-734-6404 ------------------------

Hi, I'm writing a custom alias analyser for the Glasgow Haskell Compiler's LLVM backend to teach LLVM that our explicitly-represented stack cannot alias with any heap pointer. It works, but I've hit an issue with opt's handling of alias analysers; if you specify -ghc-aa on the opt command line then LLVM only uses that analyser until (I think) a pass runs that invalidates the

Duncan Sands <baldrick <at> free.fr> writes: > > > I see the same with clang. I'm not sure why the optimizers do so much better > > when they can see that sp is a local array (the special initial values don't > > matter). > > It is the scalar replacement of aggregates pass that puts everything into > registers when sp is a local array. Yes, I

> I see the same with clang. I'm not sure why the optimizers do so much better > when they can see that sp is a local array (the special initial values don't > matter). It is the scalar replacement of aggregates pass that puts everything into registers when sp is a local array. What happens is: the tail recursion in wf is eliminated. wf is inlined into g. scalarrepl turns the

...esses from being promoted to registers. I would think they should be promoted to registers, but we will still have to write the results back to sp before returning from wf because in general we can't prove that sp is not accessed after returning from wf. -David On Nov 5, 2010, at 5:16 PM, Max Bolingbroke wrote: > Duncan Sands <baldrick <at> free.fr> writes: >> >>> I see the same with clang. I'm not sure why the optimizers do so much better >>> when they can see that sp is a local array (the special initial values don't >>> matter). >&gt...

David Peixotto <dmp <at> rice.edu> writes: > I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I rechecked this and am I actually seeing the same results as you. I think I must have made a stupid mistake in my tests before - sorry for the noise. However, I found that we have a phase ordering problem which is preventing us getting as much

Hi, The Glasgow Haskell Compiler LLVM backend is generating a lot of code which appears to be optimised by LLVM quite poorly. The problem is demonstrated by this C source code: int wf(int sp[]) { if (sp[0] == 0) { return sp[2] + sp[3]; } else { sp[3] = sp[3] + (sp[1] * 5); sp[2] = (sp[2] + sp[0]) + 1; sp[1] = sp[1] - 1; sp[0] = sp[0] - 1;