similar to: [LLVMdev] CMake builds clang.

"Anton Korobeynikov" <asl at math.spbu.ru> writes: >> at all, it would be great if you reflect your changes on the file list >> inside the corresponding CMakeLists.txt when you add, remove or rename >> a .cpp file. > > Isn't is possible for cmake just to glob everything in the corresponding > directory? Yes, but then the build would not notice a

Óscar Fuentes wrote: > "Anton Korobeynikov" <asl at math.spbu.ru> writes: > > >>> at all, it would be great if you reflect your changes on the file list >>> inside the corresponding CMakeLists.txt when you add, remove or rename >>> a .cpp file. >>> >> Isn't is possible for cmake just to glob everything in the

Anton Korobeynikov a écrit : > Hi, Oscar > >> at all, it would be great if you reflect your changes on the file list >> inside the corresponding CMakeLists.txt when you add, remove or rename > a >> .cpp file. > Isn't is possible for cmake just to glob everything in the corresponding > directory? > Hi, It is possible, but it has some drawback. Mainly, it

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> Isn't is possible for cmake just to glob everything in the corresponding >>> directory? >>> >> >> Yes, but then the build would not notice a change on the file >> structure. You'll need to explicitly invoke cmake for being sure that >> whatever changes were made by the last svn

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >>>> Isn't is possible for cmake just to glob everything in the corresponding >>>> directory? >>>> >>>> >>> Yes, but then the build would not notice a change on the file >>> structure. You'll need to explicitly invoke

-------------- next part -------------- An embedded message was scrubbed... From: "Mikael Lyngvig" <mikael at lyngvig.org> Subject: Re: [LLVMdev] An alternate implementation of exceptions Date: Sun, 6 Sep 2009 09:53:29 +0200 (CEST) Size: 6388 URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090906/ca20be9e/attachment.eml>

On Sat, Mar 6, 2010 at 11:33 AM, Cédric Venet <cedric.venet at laposte.net> wrote: > Le 06/03/2010 11:43, José Fonseca a écrit : >> >> Attached are two patches with MSVC build enchancements. >> >> They are quite trivial, but were necessary to correctly link LLVM >> libraries with Mesa3D on Windows. >> >> Jose >> > > Are you volontary

David Vandevoorde a écrit : > > I don't think those are _good_ reasons though: If one doesn't want a C+ > + function to be inlined, one shouldn't define it inline. > > You must not have written a lot of C++ template then. You don't have the choice in this case, just check your STL header. > > FWIW, I've been involved in a couple of attempts by

> Technically, yes, but we can reword future standards to have the > latitude to give compilation errors for conditions that can be proved > to be false, then the implementation is conforming. We could always > have a flag to control the behavior if people want/need it, though, I > can't hardly see why they'd want it to compile if they assert > something that

Rafael Espindola a écrit : > My proposal is to make the extension as explicit as possible. If the > callee is extending an char to an int, the generated llvm code should > return an i32 and the caller can assume that the extension has been done. > > Are you saying that the decision to do the extension in the callee happens > after we have generated llvm? That is, an optimization

Hi, Just a small patch for user of tablegen.vim I added support for: - defm and multiclass - imbricatable multiline C style comment - FIXME/TODO highlight in comment - binary and hexadecimal number - code using [{ }] is no highlighted as special (perhaps not the best choice) If someone has comment or idea to enhance, I will be happy to hear it. Regards, -- Cédric Ps: Is there somewhere a

Nuno Lopes a écrit : > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt -std-compiler-opts) is: > define i32 @y(...) nounwind { > entry:

Kenneth Boyd a écrit : > Cédric Venet wrote: >> you never seen assert(0 && "Not yet implemented"); ? >> You may want to compile a program like this :) >> > As I see it, under the proposed extension a compile-time false constant > would error "if the code commits to executing it". > > Heuristically, something like > > void

David Vandevoorde a écrit : > On Aug 27, 2009, at 3:07 AM, Cédric Venet wrote: > > >> David Vandevoorde a écrit : >> >>> I don't think those are _good_ reasons though: If one doesn't want >>> a C+ + function to be inlined, one shouldn't define it inline. >>> >>> >>> >> You must not have written a

Whoops, mailing list headers still broken, sending to the list this time: On Sat, Mar 6, 2010 at 3:35 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 11:40 AM, Cédric Venet <cedric.venet at laposte.net> wrote: >> So adding an option for adding this flag would be great but not changing the >> default. (The flag is interesting because it can

On 19 June 2015 at 15:57, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > If you just want to *link* to LLVM, it is not clear to me why you are not > just relying on LLVM being built separately and have your project CMake > pointing to the llvm build directory and using llvm-config to populate the > linker argument? > > Best, > — > Mehdi > This is

Dear All, Thanks for the feedback. To clarify, this is for LLVM-related projects that are linking against the LLVM libraries. The feature for keeping our source code in arbitrary locations isn't something we need. If we can just drop our source code into llvm/projects (or some other designated LLVM subdirectory) and write LLVM-esque CMake files, that should be enough for projects that

On Oct 26, 2008, at 11:17 AM, Óscar Fuentes wrote: >> It would be simpler for autoconf builds to have a Perl script that >> updates the CMakeLists.txt files when necessary. (This doesn't look >> *that* hard, but I can't say when I'll surface long enough to work >> on that.) > > In theory, it is possible to do this with cmake itself. In practice, >

Cédric Venet wrote: >> Technically, yes, but we can reword future standards to have the >> latitude to give compilation errors for conditions that can be proved >> to be false, then the implementation is conforming. We could always >> have a flag to control the behavior if people want/need it, though, I >> can't hardly see why they'd want it to

OvermindDL1 a écrit : > On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > >> On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> >>> On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >>> >>>> / * snip */ >>>>