similar to: [LLVMdev] C++11 is here!!! (and it looks like it'll stay!)

On Mar 2, 2014, at 10:47 PM, Chandler Carruth <chandlerc at google.com> wrote: >> I'm not aware of the prior art or standards are here, but I think that a global reverse() adapter is the way to go. Likewise, we should have a standard "enumerate()" adaptor like python. >> >> I definitely prefer the global adaptor pattern. As for prior art, I had played with

On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com> wrote: > some version of GCC and later (linux folks should pick?) 4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which is the latest Long Term Support release (which come out every 2 years, with 3 years desktop support and 5 years server support), so I wouldn't push farther than that on Linux for

On Mar 3, 2014, at 12:04 AM, Chandler Carruth <chandlerc at google.com> wrote: >> I was actually going to check in this, but I can post it for review if folks are worried. >> >> My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. > > Nice. What's the logic behind .arguments() vs

On Tue, Jan 8, 2013 at 4:17 PM, Sean Silva <silvas at purdue.edu> wrote: > On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com> wrote: >> some version of GCC and later (linux folks should pick?) > > 4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which > is the latest Long Term Support release (which come out every 2 years, > with

On 1 March 2014 19:24, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > for (auto V : X.foo()) { > ... > } +1 --renato

On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >> Another thing to bring up is that we have a lot of classes which have >> method pairs `foo_begin()` and `foo_end()` (e.g. >> `Function::arg_{begin,end}()`). These don't play nice with range-for >> loops (we are already seeing this come up in LLD). We probably should >> adopt

It's seems like a quiet and peaceful day, lets stir things up a bit :) How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: things like auto, rvalue-refs, lambdas, etc? I think that we can keep things well defined with a few simple requirements: language features must be supported by MSVC 2010 and later, some version of

This seems to indicate that the idea is a workable solution to your use case. We've still got some bikesheds to get through. (And I don't consider myself a good reviewer for Clang in this, so we need to identify who is.) As background to this extension idea, let me say that I prefer the notion that developers, particularly perf-aware developers like gamedevs, will want to handle PGO via

Sean Silva <silvas at purdue.edu> writes: > On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com> wrote: >> some version of GCC and later (linux folks should pick?) > > 4.6 is the official compiler on Ubuntu 12.04 (released 04/2012), which > is the latest Long Term Support release (which come out every 2 years, > with 3 years desktop support and 5

On Tue, Jan 8, 2013 at 6:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >>> Another thing to bring up is that we have a lot of classes which have >>> method pairs `foo_begin()` and `foo_end()` (e.g. >>> `Function::arg_{begin,end}()`). These don't play nice with

> On Dec 19, 2014, at 12:34 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > > Putting aside the several minor bikesheds we will get to if we go this route, how close does this approach get to the code shrink you were originally trying to achieve? I haven't yet adjusted my tablegen changes to take advantage of the, but it is on my list for today. > > Are there any

Hi, although I've done S3 dispatching for more than a decade now, I think I managed to overlook/avoid the following pitfall when using NextMethod(): If you explicitly pass argument '...' to NextMethod(), you will effectively pass those argument twice to the "next" method! EXAMPLE: foo0 <- function(...) UseMethod("foo0"); foo1 <- function(...)

Catching up on post-holiday emails. I may have comments on the more general stuff later, but wanted to respond to this bit more quickly. On Nov 22, 2012, at 3:05 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> s/ExecutionEngine/EE/ (or something like buzzword!) > > I don't

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile

I have looked through all of the documentation on the simple.c menu setup. I am moving from the menu with the Default, and several files *.msg my current menu launches in text and I navigate by F numbers or typing the corresponding Number next to the option that I want, I can handle setting this up, but I want a graphical background now and more customized options. So I am modifying simple.c to

neptune# ps -M vmcore.1 -N kernel.debug -axl | grep inode | wc -l 961 and I have a vmcore to work on here !! :) (kgdb) proc 99643 (kgdb) bt #0 mi_switch () at machine/globals.h:119 #1 0x8014a1f9 in tsleep (ident=0x8a4ef600, priority=8, wmesg=0x80263d4a "inode", timo=0) at /usr/src/sys/kern/kern_synch.c:479 #2 0x80141507 in acquire (lkp=0x8a4ef600, extflags=16777280,

Ok… I bit. Alex’s proposal here is really compelling to me because it means that the required changes to make this work would be more limited. Specifically a clang attribute could give us all the benefits of #ifdefs throughout the code without the maintenance burden. So, being the silly person I am, I wrote the patches for clang. I’ve never done any frontend hacking before, so take these with

Lacking any dissenting opinions, I wanted to give a heads up to folks: I plan to do the two major renamings I mentioned above this weekend. I'll do it over the weekend to try to minimize the number of patches that folks have outstanding touching files in those trees. I'll respond later this week with more details to help sort out any last questions of naming. It looks like the only real

On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at google.com> wrote: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... ->

2012/11/22 Chandler Carruth <chandlerc at google.com>: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... -> llvm/lib/IR/... > > I've