similar to: [LLVMdev] [Fwd: Re: An alternate implementation of exceptions]

Hi Duncan, I agree on the problem about linking with code - I actually do mention this in the paper. I propose adding a new calling convention called "excall". The central point of my paper is that only one parameter is needed as the return value (because of the use of the flag): the EAX register can safely be used for both the exception instance and the return value as these never

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

Hi, The guys on the Tiny C mailing list referred me to this list because I suggested adding a simple exception handling mechanism to Tiny C. I have written a small article on a proposal to add try/catch and throw statements to C, knowing very well that this is a non-standard extention, but there are so many of those in the C world that another one shouldn't be a big issue. The Tiny C guys

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

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:

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

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? -- WBR, Anton Korobeynikov

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

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

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 trying to break everyone build (just to build your own project), or have you no idea of the effect of this change:

> 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

Hi Mikael, the idea of modifying functions so they return two parameters (the usual one and an exception pointer or some kind of exception flag) is well known. The LLVM vmkit project actually uses a variant of this: rather than returning the exception pointer in a register, it sticks it in a global thread local variable. I only took a quick look at your paper, but it seems to me that it has a

OvermindDL1 a écrit : > Been trying to build the trunk to test some things for about a week > now using VS8 (VS2k5). Tons of Warnings (like things first being > declared struct, being redefined class and so forth, those need to be > fixed, but are otherwise not harmful), and a *lot* of errors. Being > trunk I figured just the normal trunk-type issues, but it has been > going on

Mikael Lyngvig <mikael at lyngvig.org> writes: [snip] > Yes, I am quite familiar with the CMake documentation, but why are you > asking? That's not the cmake documentation, that's the LLVM cmake documentation: a short document that tries to explain everything you need to know about cmake to build LLVM. I had the impression that you were duplicating a large chunk of the info

On Fri, Dec 5, 2008 at 6:38 AM, Cédric Venet <cedric.venet at laposte.net> wrote: > should be fixed with r60590 (work for me) That seems to have fixed a large amount of those errors (nicely simple fix). I went ahead and termserved into my dev box (I will not be able to get to it for another day or so) and told svn to update, and cmake to make into a new directory, and build it, but it

Stuart Hastings a écrit : > > { > {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, > {0x34800000}, {0x34a00000}, {0x34c00000}, {0x34e00000}, > {0x35000000}, {0x35100000}, {0x35200000}, {0x35300000}, > {0x35400000}, {0x35500000}, {0x35600000}, {0x35700000}, > ... > {0xfffd8000}, {0xfffda000}, {0xfffdc000}, {0xfffde000}, > {0xfffe0000},

Thank you so much for your hard work! LLVM/Clang is in need of motivated Windows developers willing to put in the time to make the LLVM/Clang experience better on Windows :) Quick note on the reST: instead of using a construct like: **Notice:** If you only want to build 32-bit programs, you do **not** need to install MinGW64. Prefer to use the reStructuredText "admonitions" <

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

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