similar to: [LLVMdev] CMake changes

On Dec 17, 2013, at 9:32 , Jordan Rose <jordan_rose at apple.com> wrote: > > On Dec 17, 2013, at 9:24 , Jordan Rose <jordan_rose at apple.com> wrote: > >> Hi, Takumi. Your CMake changes seem to be working just fine with the standalone Xcode build. However, the build products are still being put in bin/Debug instead of Debug/bin. Was that supposed to change yet? Maybe

On Dec 18, 2013, at 9:44 , Jordan Rose <jordan_rose at apple.com> wrote: > > On Dec 17, 2013, at 9:32 , Jordan Rose <jordan_rose at apple.com> wrote: > >> >> On Dec 17, 2013, at 9:24 , Jordan Rose <jordan_rose at apple.com> wrote: >> >>> Hi, Takumi. Your CMake changes seem to be working just fine with the standalone Xcode build. However,

On Dec 17, 2013, at 9:24 , Jordan Rose <jordan_rose at apple.com> wrote: > Hi, Takumi. Your CMake changes seem to be working just fine with the standalone Xcode build. However, the build products are still being put in bin/Debug instead of Debug/bin. Was that supposed to change yet? Maybe Xcode needs different settings? > > (I think I looked into this once and it was non-trivial

Hi, everyone. Today I was trying to build LLVM with libc++ and C++11 enabled, and I ran into this: http://stackoverflow.com/questions/10065384/instantiation-of-a-list-with-an-incomplete-type-in-a-typedef Basically, PBQP/Graph.h forward-declares classes, then tries to get iterators for std::lists of those classes. This is technically undefined behavior. I tried fudging with the order of

Hi, all. I noticed recently that llvm::sys::fs::createTemporaryFile does not use llvm::sys::path::system_temp_directory, instead relying on its platform-specific helper TempFile. Is there any reason for this disparity? The two implementations are not in sync, either: - TempDir honors TMPDIR, TMP, TEMP, TEMPDIR, and a configuration-settable P_tmpdir on Unix-y systems. system_temp_directory just

Hi, everyone. I was comparing our commit messages with another commit list I'm on, and I realized (not for the first time) that our subject lines are less than useful. Why don't we have the first line of our commit messages in the subject lines? Compare: [cfe-commits] r167788 - in /cfe/trunk: lib/Analysis/CFG.cpp test/Analysis/dead-stores.cpp with [cfe-commits] r167788 - Fix bad CFG

This is a known issue with the current PBQP data structures. I'm working on an overhaul of the PBQP allocator at the moment which should address this. - Lang. On Sat, Oct 20, 2012 at 2:08 PM, Benjamin Kramer <benny.kra at gmail.com>wrote: > > On 20.10.2012, at 22:47, Jordan Rose <jordan_rose at apple.com> wrote: > > > Hi, everyone. Today I was trying to build LLVM

Hello everyone, Thanks a lot for the help. -target nvptx worked great with llvm-3.2. However it gives error with -target spir. LLVM/Clang trunk although works good for both options ( probably because spir is still work in progress ). Thanks again. - Ankur On Thu, Jan 24, 2013 at 12:43 PM, Benyei, Guy <guy.benyei at intel.com> wrote: > Hi Jordan,**** > > You’re right, and

On Jan 23, 2013, at 4:04 , "Benyei, Guy" <guy.benyei at intel.com> wrote: > Hi Ankur, > Since you use –Xclang, the clang executable passes multiple triples to “clang -cc1”. You can see that if you add the -v option. I’m sure there is someone here who can explain it better than I… > Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option

On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> wrote: > I don't have much to add here besides +1. I think using std::unique_ptr > even for create* functions/methods is the right way to go. +1 smart pointers here are a win in terms of safety and self-documentation. I don't see why create* factories should be treated differently. Eli >

On 20.10.2012, at 22:47, Jordan Rose <jordan_rose at apple.com> wrote: > Hi, everyone. Today I was trying to build LLVM with libc++ and C++11 enabled, and I ran into this: > > http://stackoverflow.com/questions/10065384/instantiation-of-a-list-with-an-incomplete-type-in-a-typedef > > Basically, PBQP/Graph.h forward-declares classes, then tries to get iterators for

On Thu, Nov 15, 2012 at 2:20 PM, Jordan Rose <jordan_rose at apple.com> wrote: > Hi, everyone. I was comparing our commit messages with another commit list I'm on, and I realized (not for the first time) that our subject lines are less than useful. Why don't we have the first line of our commit messages in the subject lines? Compare: > > [cfe-commits] r167788 - in

Hi Jordan, You're right, and the driver -target option works perfectly with the SPIR triples. Thanks Guy Benyei [email_signature_guy_new2] From: Jordan Rose [mailto:jordan_rose at apple.com] Sent: Wednesday, January 23, 2013 19:47 To: Benyei, Guy Cc: ankur deshwal; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [cfe-dev] OpenCL SPIR/NVPTX code generation On Jan 23, 2013, at

I think I've fixed this issue with r166484. Let me know if you run into further problems building PBQP with libc++ and C++11. - Lang. On Sat, Oct 20, 2012 at 2:59 PM, Lang Hames <lhames at gmail.com> wrote: > This is a known issue with the current PBQP data structures. I'm working > on an overhaul of the PBQP allocator at the moment which should address > this. > >

On 25 September 2014 00:03, Tim Northover <t.p.northover at gmail.com> wrote: > I tend to follow something like that anyway so I think it's a good > idea, but if anything I'd prefer a longer title line than the body. > Particularly with the prefixes we tend to put in there, 50 chars is > hardly anything. I only mentioned 50-col because that's what Vim helps me do

Hello, NAKAMURA Takumi As you said, I check out the head from svn trunk. I build the source code as the following steps: $./configure --enable-shared $ make After 1 hour, the building procedure is stopped and appear the following error message: c:/strawberry/c/bin/../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw 32/bin/ld.exe:

Hello, everyone! 请键入文字或网站地址，或者上传文档 <http://translate.google.cn/?tr=f&hl=zh-CN>。 取消 <http://translate.google.cn/?tr=t&hl=zh-CN> I'm a newbie about llvm. Now, our project need the dynamic link library(dll) about all of llvm library, such as libLLVMCore.dll, libLLVMSupport.dll, and so on. How should I do? Thanks, yuanzheng. -------------- next part -------------- An HTML

Hello, Yuan > I'm a newbie about llvm. Now, our project need the dynamic link library(dll) > about all of llvm library, such as libLLVMCore.dll, libLLVMSupport.dll, and > so on. How should I do? You may do, "/path/to/configure --enable-shared=yes", to build LLVM-2.8svn.dll. On your project, you have to specify to linker, "-L/path/to/dll -lLLVM-2.8svn" (maybe with

Good evening, Yuan Excuse me, I gave up Debug build earlier due to my poor hosts. I will improve able to build Debug ;) You may build with --enable-optimized=yes (or, make ENABLE_OPTIMIZED=1) btw, DLL builder has implemented since Aug. It might be easier to port DLL stuff to 2.6 :) Do you try? ...Takumi 2010年9月2日 17:16:25 UTC+9 yuan zheng <tsinghuayuan86 at gmail.com>: > Hello,

Hello, I work on CMake upstream. I'd like to find out in what ways CMake upstream does not fit the needs of llvm/clang, and then fill those gaps. The recent update of the minimum version to CMake 2.8.8 is a good start. Before being able to assess what is missing, it should be ensured that the current codebase is as modern as the minimum version allows, and it needs to be cleaned up. 1)