similar to: [LLVMdev] Using C++'11 language features in LLVM itself

Chris Lattner <clattner at apple.com> writes: > 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

Seeing as I'm using OS X and Debian Sid which is on GCC 4.7.2-5 which moved over to Wheezy for Debian 7 release it seems more reasonable to target that than using Ubuntu's 4.6.x which is never more conservative than Debian on releases. - Marc P.S. I'm more interested in actually seeing if this will improve an actual smooth installation of libc++ with llvm/clang/compiler-rt trunk

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 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 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

On 1/8/2013 5:45 PM, Chris Lattner wrote: > >some version of Clang and later (Freebsd folks?). FreeBSD 9.1 uses GCC 4.2.1 and Clang 3.0, although I have some doubts about the clang, at least on PPC32. Trunk clang compiled with the system clang crashes on code that the same trunk clang compiles fine when built with gcc. It may as well be a source problem in trunk though... -Krzysztof

On 01/08/2013 03:45 PM, Chris Lattner wrote: > 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

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

I've got a simple workaround which obviously everyone will figure out: mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crti.o crti.o mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crt1.o crt1.o mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crtn.o crtn.o My real question concerns whether or not I should file a bug report against Debian not having a

Seeing as GCC 4.6 works without breaking to build LLVM instead of Clang I think I'm going to bug the Debian proper to make it easier for Clang/LLVM to get the linker update changes. After all, Debian's breaking an awful lot of stuff lately so it seems reasonable for them to add this to their To Do List. - Marc On 08/24/2011 07:15 PM, Eli Friedman wrote: > On Wed, Aug 24, 2011 at

File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt set(LLVM_TARGET_DEFINITIONS Hexagon.td) tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) tablegen(LLVM HexagonGenAsmWriter.inc -gen-asm-writer) tablegen(LLVM HexagonGenDAGISel.inc -gen-dag-isel) tablegen(LLVM HexagonGenCallingConv.inc -gen-callingconv) tablegen(LLVM

Linking CXX executable ../../../../bin/lldb Scanning dependencies of target lldb-platform [100%] Building CXX object tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o *../../../../lib/liblldb.so.3.5: undefined reference to `llvm::SmallPtrSetImpl::SmallPtrSetImpl(void const**, unsigned int, llvm::SmallPtrSetImpl&&)'** **clang: error: linker command

I keep getting this error upon building: > Linking CXX executable ../../bin/opt > ../../lib/libLLVMTarget.so: error: undefined reference to > 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData > const*, llvm::MachineInstr const*) const' > ../../lib/libLLVMTarget.so: error: undefined reference to >

On Wed, Aug 24, 2011 at 6:36 PM, Marc J. Driftmeyer <mjd at reanimality.com> wrote: > I've got a simple workaround which obviously everyone will figure out: > > mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crti.o crti.o > mdriftmeyer at horus:/usr/lib$ sudo ln -s x86_64-linux-gnu/crt1.o crt1.o > mdriftmeyer at horus:/usr/lib$ sudo ln -s

On Jun 8, 2012, at 12:52 PM, Marc J. Driftmeyer <mjd at reanimality.com> wrote: > I keep getting this error upon building: > >> Linking CXX executable ../../bin/opt >> ../../lib/libLLVMTarget.so: error: undefined reference to 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData const*, llvm::MachineInstr const*) const' >>

I flipped the build systems to use C++11 today by default. Nothing seems to have broken, folks seem happy, and the bots are making good progress. I plan to slowly remove support for building in C++98 mode over the weekend and watch the bots to see if there are any that were forcing things in the other direction. If all goes well, its open season. I've got a bunch of the basic cleanup

On Thu, Nov 29, 2012 at 9:41 AM, Joe Abbey <jabbey at arxan.com> wrote: > I know this process is well documented here > http://llvm.org/docs/GettingStarted.html > > But man do I love scripting things: > > LLVM Getting Started (See http://llvm.org/docs/GettingStarted.html) > ./getttingStarted.sh [-clang] [-compiler-rt] [-test-suite] [-branch branch] > [-dir path] [-r

Hello, I am going temporally shutdown the next few builders for maintenance works: clang-x86_64-darwin11-cross-mingw32 clang-x86_64-darwin11-self-mingw32 clang-x86_64-darwin11-cross-arm Thank you for understanding. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL:

My apologies. Shouldn't it just be removed since it is now in a subdirectory? On 12/15/2011 11:38 PM, Marc J. Driftmeyer wrote: > File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt > > set(LLVM_TARGET_DEFINITIONS Hexagon.td) > > tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) > tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) > tablegen(LLVM

Debian's response I enclose to see if this helps out: > reassign 639214 general > forcemerge 637232 639214 > quit > > Hi Marc, > > Marc J. Driftmeyer wrote: > >> With the most recent changes of moving the object files under >> /usr/lib/x86_64-linux-gnu/ the linker to build Clang/LLVM breaks. >> >> A workaround is to add symlinks for crt1.o,