* apple blocks extension @ 2009-09-15 13:28 Vincent R. 2009-09-15 13:46 ` Steven Bosscher 2009-09-15 16:04 ` Richard Henderson 0 siblings, 2 replies; 22+ messages in thread From: Vincent R. @ 2009-09-15 13:28 UTC (permalink / raw) To: gcc Hi, I just was curious to know if closures in apple gcc(called blocks from what I read) is also in mainline. What is the status about this extension ? Thanks ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 13:28 apple blocks extension Vincent R. @ 2009-09-15 13:46 ` Steven Bosscher 2009-09-15 13:59 ` Dave Korn 2009-09-15 14:03 ` Tristan Gingold 2009-09-15 16:04 ` Richard Henderson 1 sibling, 2 replies; 22+ messages in thread From: Steven Bosscher @ 2009-09-15 13:46 UTC (permalink / raw) To: Vincent R.; +Cc: gcc On Tue, Sep 15, 2009 at 3:28 PM, Vincent R. <forumer@smartmobili.com> wrote: > Hi, > > I just was curious to know if closures in apple gcc(called blocks from > what I read) is > also in mainline. > What is the status about this extension ? Hi, The status is that there is no status, unfortunately (it's an interesting extension...). This extension is not presently implemented in the FSF GCC. AFAIU there is no reason to believe Apple will contribute patches to implement it. Is there even a formal spec for the language extension? Ciao! Steven ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 13:46 ` Steven Bosscher @ 2009-09-15 13:59 ` Dave Korn 2009-09-15 14:03 ` Tristan Gingold 1 sibling, 0 replies; 22+ messages in thread From: Dave Korn @ 2009-09-15 13:59 UTC (permalink / raw) To: Steven Bosscher; +Cc: Vincent R., gcc Steven Bosscher wrote: > Is there even a formal spec for the language extension? I think it's http://clang.llvm.org/docs/BlockLanguageSpec.txt as that's the one they've referred to in their white paper (wg14/n1370). It's not written in your typical standardese as yet, though, from what I could find. cheers, DaveK ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 13:46 ` Steven Bosscher 2009-09-15 13:59 ` Dave Korn @ 2009-09-15 14:03 ` Tristan Gingold 2009-09-15 14:21 ` Vincent R. 2009-09-15 17:03 ` Michael Meissner 1 sibling, 2 replies; 22+ messages in thread From: Tristan Gingold @ 2009-09-15 14:03 UTC (permalink / raw) To: Steven Bosscher; +Cc: Vincent R., gcc On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote: > > Hi, > > The status is that there is no status, unfortunately (it's an > interesting extension...). > > This extension is not presently implemented in the FSF GCC. > AFAIU there is no reason to believe Apple will contribute patches to > implement it. I think you may (are allowed to) port it from Apple GCC sources. Tristan. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 14:03 ` Tristan Gingold @ 2009-09-15 14:21 ` Vincent R. 2009-09-15 17:03 ` Michael Meissner 1 sibling, 0 replies; 22+ messages in thread From: Vincent R. @ 2009-09-15 14:21 UTC (permalink / raw) To: gcc On Tue, 15 Sep 2009 16:03:35 +0200, Tristan Gingold <gingold@adacore.com> wrote: > On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote: >> >> Hi, >> >> The status is that there is no status, unfortunately (it's an >> interesting extension...). >> >> This extension is not presently implemented in the FSF GCC. >> AFAIU there is no reason to believe Apple will contribute patches to >> implement it. > > I think you may (are allowed to) port it from Apple GCC sources. I don't have time nor skills but I think it's an interesting feature and I wouldn't like clang to be the only compiler to have it. Besides if gcc implements it too it would make a kind of standard... But maybe true C programmers find that it's nothing more than a syntaxic sugar but I would answer that C is just syntaxic sugar for ASM ;-) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 14:03 ` Tristan Gingold 2009-09-15 14:21 ` Vincent R. @ 2009-09-15 17:03 ` Michael Meissner 1 sibling, 0 replies; 22+ messages in thread From: Michael Meissner @ 2009-09-15 17:03 UTC (permalink / raw) To: Tristan Gingold; +Cc: Steven Bosscher, Vincent R., gcc On Tue, Sep 15, 2009 at 04:03:35PM +0200, Tristan Gingold wrote: > > On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote: > > > >Hi, > > > >The status is that there is no status, unfortunately (it's an > >interesting extension...). > > > >This extension is not presently implemented in the FSF GCC. > >AFAIU there is no reason to believe Apple will contribute patches to > >implement it. > > I think you may (are allowed to) port it from Apple GCC sources. If you are not the copyright owner of the sources, I doubt the FSF would allow it to be checked into GCC. However, a reimplementation from scratch would be doable. Like everything else in the free software world, it depends on the motavations of the people contributing the code. To paraphrase president Kennedy, ask not what GCC can do for you, ask what you can do for GCC? So roll up your sleeves and get coding, or convince other people (and their managers) that it is a good thing to do. I suspect there are people starting to think about it, and perhaps the interested parties need to organize to scope out the work. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meissner@linux.vnet.ibm.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 13:28 apple blocks extension Vincent R. 2009-09-15 13:46 ` Steven Bosscher @ 2009-09-15 16:04 ` Richard Henderson 2009-09-15 16:21 ` Ed Smith-Rowland 2009-09-15 16:35 ` Chris Lattner 1 sibling, 2 replies; 22+ messages in thread From: Richard Henderson @ 2009-09-15 16:04 UTC (permalink / raw) To: Vincent R.; +Cc: gcc On 09/15/2009 08:28 AM, Vincent R. wrote: > I just was curious to know if closures in apple gcc(called blocks from > what I read) is > also in mainline. > What is the status about this extension ? It is unlikely that this will ever be brought into GCC, since it appears to be largely identical to the C++0x Lambda feature. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:04 ` Richard Henderson @ 2009-09-15 16:21 ` Ed Smith-Rowland 2009-09-15 16:50 ` Ian Lance Taylor 2009-09-15 16:35 ` Chris Lattner 1 sibling, 1 reply; 22+ messages in thread From: Ed Smith-Rowland @ 2009-09-15 16:21 UTC (permalink / raw) To: Richard Henderson; +Cc: Vincent R., gcc Richard Henderson wrote: > On 09/15/2009 08:28 AM, Vincent R. wrote: >> I just was curious to know if closures in apple gcc(called blocks from >> what I read) is >> also in mainline. >> What is the status about this extension ? > > It is unlikely that this will ever be brought into GCC, since > it appears to be largely identical to the C++0x Lambda feature. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf > > > r~ > I agree that it is superfluous for C++ at this stage but it might be nice for Objective-C (regular C) although Objective-C++ will then have to be taught how to deal with it somehow anyway. OTOH, with lambdas it might be more easy to put this in.* It is probably just a special case of lambdas. We'd have to find out which one of course. I think syntactically it shouldn't be too bad.** In general, and this has come up before, there are other things in Objective-C 2.0 that we don't have. IIRC the Apple trees left behind are a little old and not in good shape. What are the licensing issues for borrowing from LLVM leaving aside the technical issues? ed * Or not. I think C++ lambdas are implemented as a little class of some type which might make C mad. ** I was noticing that C++ lambdas and Obj-C message passing syntax collides a little. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:21 ` Ed Smith-Rowland @ 2009-09-15 16:50 ` Ian Lance Taylor 2009-09-16 15:50 ` Mark Mitchell 0 siblings, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2009-09-15 16:50 UTC (permalink / raw) To: Ed Smith-Rowland; +Cc: Richard Henderson, Vincent R., gcc Ed Smith-Rowland <3dw4rd@verizon.net> writes: > In general, and this has come up before, there are other things in > Objective-C 2.0 that we don't have. IIRC the Apple trees left behind > are a little old and not in good shape. What are the licensing issues > for borrowing from LLVM leaving aside the technical issues? There is no issue with looking at LLVM or Apple's version of gcc and reimplementing the ideas in gcc. Actual code copying depends upon the copyright status of the Apple code. Although Apple has chosen to stop contributing to the FSF, they have signed a perpetual copyright assignment for changes to several FSF programs. So it seems to me that any changes that Apple makes to gcc (or gdb, emacs, etc.) can simply be brought over by any interested party. I don't know how this interacts with changes to LLVM. However, it is fairly unlikely that those changes could be copied directly anyhow. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:50 ` Ian Lance Taylor @ 2009-09-16 15:50 ` Mark Mitchell 2009-09-16 16:21 ` Ian Lance Taylor 0 siblings, 1 reply; 22+ messages in thread From: Mark Mitchell @ 2009-09-16 15:50 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Ed Smith-Rowland, Richard Henderson, Vincent R., gcc Ian Lance Taylor wrote: > programs. So it seems to me that any changes that Apple makes to gcc > (or gdb, emacs, etc.) can simply be brought over by any interested > party. I'd certainly check with the FSF before betting on that. ISTR that some copyright assignments have a "contribution" step; simple publication may not be sufficient. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-16 15:50 ` Mark Mitchell @ 2009-09-16 16:21 ` Ian Lance Taylor 2009-09-16 18:12 ` Vincent R. 2009-09-16 23:57 ` Linda A. Walsh 0 siblings, 2 replies; 22+ messages in thread From: Ian Lance Taylor @ 2009-09-16 16:21 UTC (permalink / raw) To: Mark Mitchell; +Cc: Ed Smith-Rowland, Richard Henderson, Vincent R., gcc Mark Mitchell <mark@codesourcery.com> writes: > Ian Lance Taylor wrote: > >> programs. So it seems to me that any changes that Apple makes to gcc >> (or gdb, emacs, etc.) can simply be brought over by any interested >> party. > > I'd certainly check with the FSF before betting on that. ISTR that some > copyright assignments have a "contribution" step; simple publication may > not be sufficient. True, though Apple's entry in the copyright file says "assigns past and future changes" (I checked before the above e-mail). Certainly checking with the FSF is a good idea. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-16 16:21 ` Ian Lance Taylor @ 2009-09-16 18:12 ` Vincent R. 2009-09-16 18:40 ` Chris Lattner 2009-09-16 23:57 ` Linda A. Walsh 1 sibling, 1 reply; 22+ messages in thread From: Vincent R. @ 2009-09-16 18:12 UTC (permalink / raw) To: gcc On Wed, 16 Sep 2009 09:20:58 -0700, Ian Lance Taylor <iant@google.com> wrote: > Mark Mitchell <mark@codesourcery.com> writes: > >> Ian Lance Taylor wrote: >> >>> programs. So it seems to me that any changes that Apple makes to gcc >>> (or gdb, emacs, etc.) can simply be brought over by any interested >>> party. >> >> I'd certainly check with the FSF before betting on that. ISTR that some >> copyright assignments have a "contribution" step; simple publication may >> not be sufficient. > > True, though Apple's entry in the copyright file says "assigns past and > future changes" (I checked before the above e-mail). Certainly checking > with the FSF is a good idea. > > Ian While we are discussing apple extension, is there a list of apple specific extension about C and objective compiler ? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-16 18:12 ` Vincent R. @ 2009-09-16 18:40 ` Chris Lattner 2009-09-16 19:05 ` Dave Korn 0 siblings, 1 reply; 22+ messages in thread From: Chris Lattner @ 2009-09-16 18:40 UTC (permalink / raw) To: Vincent R.; +Cc: gcc On Sep 16, 2009, at 11:12 AM, Vincent R. wrote: >> True, though Apple's entry in the copyright file says "assigns past >> and >> future changes" (I checked before the above e-mail). Certainly >> checking >> with the FSF is a good idea. >> >> Ian > > While we are discussing apple extension, is there a list of apple > specific > extension about > C and objective compiler ? There isn't anything good, but some information is available here: http://clang.llvm.org/docs/LanguageExtensions.html -Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-16 18:40 ` Chris Lattner @ 2009-09-16 19:05 ` Dave Korn 0 siblings, 0 replies; 22+ messages in thread From: Dave Korn @ 2009-09-16 19:05 UTC (permalink / raw) To: Chris Lattner; +Cc: Vincent R., gcc Chris Lattner wrote: > On Sep 16, 2009, at 11:12 AM, Vincent R. wrote: >> While we are discussing apple extension, is there a list of apple >> specific extension about C and objective compiler ? > > There isn't anything good, but some information is available here: > http://clang.llvm.org/docs/LanguageExtensions.html > > -Chris See also Garst, "Apple's extensions to C", submitted to WG14: http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1370.pdf cheers, DaveK ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-16 16:21 ` Ian Lance Taylor 2009-09-16 18:12 ` Vincent R. @ 2009-09-16 23:57 ` Linda A. Walsh 1 sibling, 0 replies; 22+ messages in thread From: Linda A. Walsh @ 2009-09-16 23:57 UTC (permalink / raw) To: gcc Ian Lance Taylor wrote: > Mark Mitchell writes "I'd certainly check with the FSF > > before betting on that. " > True, though Apple's entry in the copyright file says "assigns past and > future changes" (I checked before the above e-mail). Certainly checking > with the FSF is a good idea. --- Conceptually, it's not 'rocket science' It's just providing some allocated memory to a procedure that it uses as it's memory, (versus memory on stack that goes away when function returns) whenever it is called and for as long as the function stays "active" (hasn't explicitly released it's allocated memory). Perl has had similar things and nearly an entire book(Higher Order Perl, M.J. Dominus) was written about their use (it's a really good book, in my opinion -- it's not really perl specific (though everything is in perl), but I found it provided me with a fairly good understanding of closures as used with named or anonymous functions. I believe the mention it's taken from lisp's lambda operator that did much the same. -l ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:04 ` Richard Henderson 2009-09-15 16:21 ` Ed Smith-Rowland @ 2009-09-15 16:35 ` Chris Lattner 2009-09-17 0:05 ` Linda A. Walsh 2009-09-24 14:57 ` Jason Merrill 1 sibling, 2 replies; 22+ messages in thread From: Chris Lattner @ 2009-09-15 16:35 UTC (permalink / raw) To: Richard Henderson; +Cc: Vincent R., gcc On Sep 15, 2009, at 9:04 AM, Richard Henderson wrote: > On 09/15/2009 08:28 AM, Vincent R. wrote: >> I just was curious to know if closures in apple gcc(called blocks >> from >> what I read) is >> also in mainline. >> What is the status about this extension ? > > It is unlikely that this will ever be brought into GCC, since > it appears to be largely identical to the C++0x Lambda feature. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf There are major differences between lambdas and blocks, though they serve a superficially similar purpose. If you are interested, there is a ton of discussion online. Here are the two biggest differences: The first difference is that every instance of a lambda gives you a value of a new (anonymous) type, which makes them mostly only useful with templates. Blocks literals give values of a predictable type, which means that you can pass them around to non-templates. This is also why they "work" in C. Yes, I know that there are various adaptor classes that can be used with C++ lambdas to help work around this, but this is in inherent part of blocks. The second major feature of Blocks vs c++ lambdas is that they can be "copied onto the heap". This allows things like "Grand Central Dispatch" to work: you can write code that executes blocks asynchronously or on other threads/work queues (after the function containing the block has returned). A simple example is: void print_on_different_thread(int X) { run_asynch(^{ printf("Hi %d\n", X); }); } With lambdas, the closure would be go out of scope when print_on_different_thread returns, but blocks allows "run_asynch" to extend the lifetime of the block. Blocks and Lambdas have intentionally different syntax, allowing them to coexist peacefully in the same compiler / language. They are also superficially similar to nested functions, but have other sets of benefits. For example, blocks don't require executable stacks etc. -Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:35 ` Chris Lattner @ 2009-09-17 0:05 ` Linda A. Walsh 2009-09-24 14:57 ` Jason Merrill 1 sibling, 0 replies; 22+ messages in thread From: Linda A. Walsh @ 2009-09-17 0:05 UTC (permalink / raw) To: Chris Lattner; +Cc: gcc Chris Lattner wrote: > The first difference is that every instance of a lambda gives you a > value of a new (anonymous) type, which makes them mostly only useful > with templates. --- Ahh..didn't know that. That certainly would make them less useful in a general sense. I've only been exposed to the 'definable-value, returned' variety as being the main type used and talked about in the 'higher order perl' (higher order, that instead of working on data, you have functions working on other functions that that may work on the data (or call other functions, I suppose! ;-)). Seems like a good way to provide automatically compatibility layers for data marshaling so that other layers don't have to know about what's really in the lower layers, ala an OSI network model. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-15 16:35 ` Chris Lattner 2009-09-17 0:05 ` Linda A. Walsh @ 2009-09-24 14:57 ` Jason Merrill 2009-09-24 15:23 ` Chris Lattner 1 sibling, 1 reply; 22+ messages in thread From: Jason Merrill @ 2009-09-24 14:57 UTC (permalink / raw) To: Chris Lattner; +Cc: Richard Henderson, Vincent R., gcc@gcc.gnu.org >> GCC On 09/15/2009 12:35 PM, Chris Lattner wrote: > The second major feature of Blocks vs c++ lambdas is that they can be > "copied onto the heap". This allows things like "Grand Central Dispatch" > to work: you can write code that executes blocks asynchronously or on > other threads/work queues (after the function containing the block has > returned). A simple example is: > > void print_on_different_thread(int X) { > run_asynch(^{ > printf("Hi %d\n", X); > }); > } > > With lambdas, the closure would be go out of scope when > print_on_different_thread returns, but blocks allows "run_asynch" to > extend the lifetime of the block. The lambda equivalent would be void print_on_different_thread(int X) { run_asynch([=]{ printf("Hi %d\n", X); }); } since X is captured by copy, run_asynch can do whatever it wants with the closure and not worry about the original X going away. The only difference between blocks and lambdas here seems to be where you decide to copy the locals off the stack. Jason ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-24 14:57 ` Jason Merrill @ 2009-09-24 15:23 ` Chris Lattner 2009-09-24 16:53 ` Jason Merrill 0 siblings, 1 reply; 22+ messages in thread From: Chris Lattner @ 2009-09-24 15:23 UTC (permalink / raw) To: Jason Merrill; +Cc: Richard Henderson, Vincent R., gcc@gcc.gnu.org >> GCC On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote: > On 09/15/2009 12:35 PM, Chris Lattner wrote: >> The second major feature of Blocks vs c++ lambdas is that they can be >> "copied onto the heap". This allows things like "Grand Central >> Dispatch" >> to work: you can write code that executes blocks asynchronously or on >> other threads/work queues (after the function containing the block >> has >> returned). A simple example is: >> >> void print_on_different_thread(int X) { >> run_asynch(^{ >> printf("Hi %d\n", X); >> }); >> } >> >> With lambdas, the closure would be go out of scope when >> print_on_different_thread returns, but blocks allows "run_asynch" to >> extend the lifetime of the block. > > The lambda equivalent would be > > void print_on_different_thread(int X) { > run_asynch([=]{ > printf("Hi %d\n", X); > }); > } > > since X is captured by copy, run_asynch can do whatever it wants > with the closure and not worry about the original X going away. > > The only difference between blocks and lambdas here seems to be > where you decide to copy the locals off the stack. Can the lambda (containing X) be copied and put onto a queue? What is its type? -Chris ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-24 15:23 ` Chris Lattner @ 2009-09-24 16:53 ` Jason Merrill 2009-09-24 20:41 ` Jason Merrill 2009-09-25 16:55 ` Vincent R. 0 siblings, 2 replies; 22+ messages in thread From: Jason Merrill @ 2009-09-24 16:53 UTC (permalink / raw) To: Chris Lattner; +Cc: Richard Henderson, Vincent R., gcc@gcc.gnu.org >> GCC On 09/24/2009 11:22 AM, Chris Lattner wrote: > Can the lambda (containing X) be copied and put onto a queue? What is > its type? As you said, the lambda has a unique anonymous type. If you want to put multiple lambdas into a container, you can use std::function as the element type. Jason ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-24 16:53 ` Jason Merrill @ 2009-09-24 20:41 ` Jason Merrill 2009-09-25 16:55 ` Vincent R. 1 sibling, 0 replies; 22+ messages in thread From: Jason Merrill @ 2009-09-24 20:41 UTC (permalink / raw) To: gcc; +Cc: Richard Henderson, Vincent R., gcc@gcc.gnu.org >> GCC On 09/24/2009 11:22 AM, Chris Lattner wrote: > Can the lambda (containing X) be copied and put onto a queue? What is > its type? As you said, the lambda has a unique anonymous type. If you want to put multiple lambdas into a container, you can use std::function as the element type. Jason ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: apple blocks extension 2009-09-24 16:53 ` Jason Merrill 2009-09-24 20:41 ` Jason Merrill @ 2009-09-25 16:55 ` Vincent R. 1 sibling, 0 replies; 22+ messages in thread From: Vincent R. @ 2009-09-25 16:55 UTC (permalink / raw) To: gcc On Thu, 24 Sep 2009 12:53:04 -0400, Jason Merrill <jason@redhat.com> wrote: > On 09/24/2009 11:22 AM, Chris Lattner wrote: >> Can the lambda (containing X) be copied and put onto a queue? What is >> its type? > > As you said, the lambda has a unique anonymous type. If you want to put > multiple lambdas into a container, you can use std::function as the > element type. > > Jason There was a discussion about rights to report blocks implementation into gcc trunk, what does FSF think about this ? Is it allowed ? ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-09-25 16:31 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-15 13:28 apple blocks extension Vincent R. 2009-09-15 13:46 ` Steven Bosscher 2009-09-15 13:59 ` Dave Korn 2009-09-15 14:03 ` Tristan Gingold 2009-09-15 14:21 ` Vincent R. 2009-09-15 17:03 ` Michael Meissner 2009-09-15 16:04 ` Richard Henderson 2009-09-15 16:21 ` Ed Smith-Rowland 2009-09-15 16:50 ` Ian Lance Taylor 2009-09-16 15:50 ` Mark Mitchell 2009-09-16 16:21 ` Ian Lance Taylor 2009-09-16 18:12 ` Vincent R. 2009-09-16 18:40 ` Chris Lattner 2009-09-16 19:05 ` Dave Korn 2009-09-16 23:57 ` Linda A. Walsh 2009-09-15 16:35 ` Chris Lattner 2009-09-17 0:05 ` Linda A. Walsh 2009-09-24 14:57 ` Jason Merrill 2009-09-24 15:23 ` Chris Lattner 2009-09-24 16:53 ` Jason Merrill 2009-09-24 20:41 ` Jason Merrill 2009-09-25 16:55 ` Vincent R.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).