search for: laudabl

...est of > breed section based linker. It will support linker scripts and do > everything better than any existing section based linker. The first > step of this is to do what Rui proposes and rip atoms out of the model. This is another item that has been irritating me. While it is a very laudable goal to not depend on linker scripts for the common case, not having the functionality of fine grained output control is certainly a problem. They are crucial for embedded developers and also at least significant for anything near a system kernel. > We will also build a no-holds-barred awesome...

...on based linker. It will support linker scripts and do >> everything better than any existing section based linker. The first >> step of this is to do what Rui proposes and rip atoms out of the model. > > This is another item that has been irritating me. While it is a very > laudable goal to not depend on linker scripts for the common case, not > having the functionality of fine grained output control is certainly a > problem. They are crucial for embedded developers and also at least > significant for anything near a system kernel. I’m not saying that the linker sho...

...y various alternatives on a new hardware platform is very useful. | Instead of providing facilities to tune the hardware, we should | understand why LLVM does not choose the right unrolling factor. Maybe | there is additional information that can help LLVM to derive that | information. This is a laudable goal, but there always comes up the issue that developing understanding of why things perform in a particular way on a modern CPU/memory/chipset combination requires manpower, often more manpower than is available. Regards, Dave

Hi all, I'm interested in participating this GSoC with llvm. I would like to contribute on the project idea "DebugInfo should not effect codegen". Over the past few days, I have gone through some bugs reported at bugzilla that cause different codegen behavior of same program. Bugs I have been looking at are:     1. [fuzzDI] -O1 + `-g` cause the generated code to change.

...sed the commit at the time but there are few remarks I would like to make: 1) The motivation for this change, at least from what I understand, is trying to optimize `check-llvm`. As somebody who spends a fair amount of time tapping fingers while waiting for the tests to run, I do believe this is a laudable goal, but I'm uncertain of the results. In fact, it seems it only saves 1 second (according to the commit message). 2) I can't speak for anybody else, but I'm not entirely sure a 48-cores box is a common setup (I might be completely wrong on this one, but I have [and had] access to muc...

Hi! Attached patch makes xen-tools and stubdom-dm going independent from hardcoded pathes. It is no possible to install into /usr/local or any other non-default directory and use it out-of-the box. This allows us to have different Xen versions in different directories, simplifies packaging for distributions. It also finds ''hvmloader'' and

I am planning to configure * box A with PSTN interface to route faxes to * box B (running spandsp) over TDMoE. I am using 2xGb bonded NIC's for connection between servers. Was wondering - does anybody have experience with TDMoE over bonded interface - ie. does it work ok?. - does anybody have feedback using this scenario for fax? another question, perhaps someone knows what's the

...remarks I >> would like to make: >> 1) The motivation for this change, at least from what I understand, is >> trying to optimize `check-llvm`. As somebody who spends a fair amount >> of time tapping fingers while waiting for the tests to run, I do >> believe this is a laudable goal, but I'm uncertain of the results. In >> fact, it seems it only saves 1 second (according to the commit >> message). > > > There were a string of related commits here, not just one. They added up at the time. > >> >> 2) I can't speak for anybody els...

On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: > On 11/21/2012 6:53 AM, Tobias Grosser wrote: >> >> o Blocks future optimizations >> >> At the moment LLVM performs little loop optimizations. Hence, the >> original structure is not changed too much. > > I'm thinking of this in terms of parallelization directives. The > optimizations that rely on

Well, today, I feel like a real, old time sysadmin. Now, I didn't have to write a driver in assembly for the printer, but.... We got this huge, 44" HP Designjet z3200ps printer. Only supports Win and Mac. Fine, I hang it off of one of our servers on a subnet (at $0.96/foot paper, we're the only ones who print on it....). Then I'm thinking that all I really need is a .ppd. My

...for splitting sections into atoms would become * ELF/COFF: one atom per section. * MachO: One atom per global symbol. And so MachO ends up with atoms that have only one symbol, but that is just a special case. >> This is another item that has been irritating me. While it is a very >> laudable goal to not depend on linker scripts for the common case, not >> having the functionality of fine grained output control is certainly a >> problem. They are crucial for embedded developers and also at least >> significant for anything near a system kernel. > > I’m not sayin...

...l support linker scripts and do > >> everything better than any existing section based linker. The first > >> step of this is to do what Rui proposes and rip atoms out of the model. > > > > This is another item that has been irritating me. While it is a very > > laudable goal to not depend on linker scripts for the common case, not > > having the functionality of fine grained output control is certainly a > > problem. They are crucial for embedded developers and also at least > > significant for anything near a system kernel. > > I’m not sa...

On 11/21/2012 6:53 AM, Tobias Grosser wrote: > > o Blocks future optimizations > > At the moment LLVM performs little loop optimizations. Hence, the > original structure is not changed too much. I'm thinking of this in terms of parallelization directives. The optimizations that rely on such annotations would need to be done as early as possible, before any optimization that

Hi, I just committed this: > - djm at cvs.openbsd.org 2010/04/16 01:47:26 > [PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c] > [auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c] > [ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c] > [sshconnect.c sshconnect2.c sshd.c] > revised certificate format ssh-{dss,rsa}-cert-v01 at

I was asked by my boss to do an analysis on a large data set, and I am trying to convince him to let me use R rather than SPSS. I think Sweave could make my life much much easier. To get me a little closer to this goal, I ran my analysis through R and SPSS and compared the resulting values. In all but one case, they were the same. Given the matrix [,1] [,2] [1,] 110 358 [2,] 71 312 [3,]

...cannot achieve by saying "native"="relocatable ELF"? -- Sean Silva > > And so MachO ends up with atoms that have only one symbol, but that is > just a special case. > > >> This is another item that has been irritating me. While it is a very > >> laudable goal to not depend on linker scripts for the common case, not > >> having the functionality of fine grained output control is certainly a > >> problem. They are crucial for embedded developers and also at least > >> significant for anything near a system kernel. > &gt...

Hello all! I find that using lldb to debug LLVM libraries can be super frustrating, because a lot of LLVM classes, like the constructor for StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt to have lldb evaluate an expression that implicitly instantiates a StringRef, I get 'error: Couldn't lookup symbols: __ZN4llvm9StringRefC1EPKc'. As an example, most recently

On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Proposal > Re-architect the linker based on the section model where it’s appropriate. > Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior. Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.

(quoting from the web archive, I only just subscribed) Monty wrote: > > > (a bit testy that this flamewar has started again, and no one has learned a > > thing from the previous rounds) > > OK, that wasn't fair... the old timers know what's up, but I do wish some of > the folks who bring things up would browse the archive threads or at least not > jump in

Hello, I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, and I've recently been asked about ACL support in rsync by Eric. Upon investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I also found some other postings to rsync@lists.samba.org concerning rsync and ACLs [3]. Are there any plans for finalizing an integrating that rsync ACL patch? I