similar to: [LLVMdev] Update VS2005

Hi, Last time patch contained a new file, but it seems this is not supported so I attached it here: Common.vsprops => llvm/win32/ This allow to set properties (like preprocessor definition) to all the project at the same time. And a patch for the recent file add/remove on legalizetype. Regards, Cédric Ps: perhaps I should post on llvm-commit for this kind of things? I would then need to

Thanks cedric, I will look into the ways the debug information could be used. However, it seems like i would have to write a piece of code that would successively reduce the conditional predicate in terms of the local and global variables (of the code). I plan to do it like this. Since i am using a runonBasicblock pass, the context information between two basic blocks cannot be shared, since

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, Just a small update for the project files for adding a missing preprocessor definition for VS2005 (without SP1). It suppress the (bogus) M$ deprecated warning. Regards, Cédric Ps: perhaps I should update to SP1 instead :) -------------- next part -------------- A non-text attachment was scrubbed... Name: updVS2005prj080612.patch Type: application/octet-stream Size: 31834 bytes Desc: not

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

On Fri, Dec 5, 2008 at 2:31 PM, Cédric Venet <cedric.venet at laposte.net> wrote: > 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

On Sat, Mar 6, 2010 at 4:08 PM, Isaac Dupree <ml at isaac.cedarswampstudios.org> wrote: > On 03/06/10 18:03, OvermindDL1 wrote: >> >> On Sat, Mar 6, 2010 at 3:57 PM, Isaac Dupree >> <ml at isaac.cedarswampstudios.org>  wrote: >>> >>> On 03/06/10 17:37, OvermindDL1 wrote: >>>> >>>> Whoops, mailing list headers still broken,

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

Cedric is right, Our target, PIC16, is 8-bit and promotion to 32-bit is really bad for us... Now what exactly is going to happen once these attributes are added, depends on the target. For example, in our case, there will be no promotion on the callee side, but the caller will decide if it wants to promote or not... What will happen in general is that front-end (clang and llvm-gcc) will do the

Hi, Three new files added: lib\Analysis\ValueTracking.cpp lib\CodeGen\StackSlotColoring.cpp lib\CodeGen\LiveStackAnalysis.cpp Regards, Cédric -------------- next part -------------- A non-text attachment was scrubbed... Name: updVS2005prj.patch Type: application/octet-stream Size: 1064 bytes Desc: not available URL:

On Fri, Dec 5, 2008 at 12:45 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > 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

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

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

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 lot of C++ template then. (Ha!) > You don't have the choice in this case, just

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

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:

On Apr 27, 2008, at 7:37 AM, Cédric Venet wrote: > Hi, > > I am trying to do a backend to a very simple microcontroller. I have > some > questions. Ok. > 1) I have instruction which do "r1 <- r1 op r2", from what I have > ssen I > must declare them like: > > let isTwoAddress = 1 in > def ADD : FopRR< 0b01010, > (outs

Hi, Some random sample of VS warning: Lot of 64 bits conversions: AsmPrinter.cpp ..\..\lib\CodeGen\AsmPrinter.cpp(277) : warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\AsmPrinter.cpp(614) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int', possible loss of data

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