On 28 October 2013 20:22, Joakim <joa...@airpost.net> wrote: > On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote: >> >> On 28 October 2013 18:38, Joseph Rushton Wakeling >> <joseph.wakel...@webdrake.net> wrote: >>> >>> It certainly seems to be true that LLVM is moving faster innovation-wise. >>> I >>> don't know how much of that is down to any architectural advantages, how >>> much might be because they support less targets and so have a lower >>> maintenance burden, and how much of it is just the scale of resources >>> being >>> put into it. >>> >> >> I don't see it that way. Up until now at least I haven't seen >> anything they do that wasn't already do-able in GCC. They just do a >> better job at PR (which is what you expect from Apple anyway). > > Really? The claims that llvm has a cleaner codebase, is easier to use > because it's all properly split up into different libraries, and introduces > new features like better error reporting: that's all "PR?"
GCC approach to libraries has not been to load them dynamically, take libiberty for example: http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using - and the "better" error reporting was in gcc, just off by default (Clang added a little more with addition of ~~ tildas ~~). >From what I've read and gathered from David over a period of some conversations. Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations. The direction that GCC went in later versions was closing the backdoor and moving backend-specific code in various frontends to the middle end. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
