similar to: Why does wine always use the worst font it can find?

On 28.08.2012 14:47, Cameron Zwarich wrote: > On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > >> On 28.08.2012 14:08, Joshua Cranmer wrote: >>> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>>> I think the C backend also allow people performing source-to-source >>>> transform with LLVM (instead of Clang). >>>

On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > On 28.08.2012 14:08, Joshua Cranmer wrote: >> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>> I think the C backend also allow people performing source-to-source >>> transform with LLVM (instead of Clang). >> >> I do not believe that this would be the case nor that it should

On 28.08.2012 14:08, Joshua Cranmer wrote: > On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >> I think the C backend also allow people performing source-to-source >> transform with LLVM (instead of Clang). > > I do not believe that this would be the case nor that it should be a > goal. Source-to-source transformation requires a lot of accurate > information about the AST,

Will this allow users to compile C++ (or some other language that LLVM has a frontend for) to C, which then can be compiled using a C compiler for a target architecture, for which only a C compiler exists? Which use-cases do you have in mind for this backend? Philipp

I think the C backend also allow people performing source-to-source transform with LLVM (instead of Clang). ether On Tue, Aug 28, 2012 at 10:30 AM, Philipp Klaus Krause <pkk at spth.de> wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only

Even though wine versions get released often and the weekly newsletters seem to report progress I get the impression that wine is not really improving. Of course it happens that some applications work with newer wine versions which didn't work with older ones, but at the same time old applications stop working. Is it only me that gets the impression that wine only changes over time, but

Warning: Sligthly off topic. http://shelleytherepublican.com/2006/04/linux-european-threat-to-our-computers.html Quotes: > And guess what software Osama Bin Laden uses on his laptop? > > If you guessed it was Linux you would be 100% right. > Next time somebody asks you how Al Queda agents pay for their > rifles and rocket launchers, you can tell them that foreign hackers >

Hello all, I am in need for a working C back-end for LLVM for my current research. I know that the previous incarnation of this back-end has been kicked out of the tree since the 3.1 release and I have gone through the archives to restore it to it's previous 'glory'. So far, I have restored most of the previous version (excluding some of the parts that needed changes outside of

Hi Philipp, On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > > > Note that C and LLVM types are *not* the same things (despite the > > similar names). We are in the process of making this abundantly clear. > > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless > > integer quantities of specific sizes,

Reid Spencer schrieb: > Hi Philipp, > > On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause wrote: >> Reid Spencer schrieb: >> >>> Note that C and LLVM types are *not* the same things (despite the >>> similar names). We are in the process of making this abundantly clear. >>> The LLVM IR will soon use names like i8, i16, i32, and i64 (signless

On Thu, 2006-11-23 at 19:10 +0100, Philipp Klaus Krause wrote: > Pertti Kellomäki schrieb: > > Chris Lattner wrote: > >> Many aspects of the target compiler can leak through. > > > > So if one wants to use the LLVM system as a cross compiler, one > > has to configure llvm-gcc as a cross compiler? Fair enough, I guess. > > I hope the C backend is still

Reid Spencer schrieb: > On Thu, 2006-11-23 at 19:10 +0100, Philipp Klaus Krause wrote: >> Pertti Kellomäki schrieb: >>> Chris Lattner wrote: >>>> Many aspects of the target compiler can leak through. >>> So if one wants to use the LLVM system as a cross compiler, one >>> has to configure llvm-gcc as a cross compiler? Fair enough, I guess. >> I

Pertti Kellomäki schrieb: > Chris Lattner wrote: >> Many aspects of the target compiler can leak through. > > So if one wants to use the LLVM system as a cross compiler, one > has to configure llvm-gcc as a cross compiler? Fair enough, I guess. I hope the C backend is still meant to generate portable code though. Philipp

Reid Spencer schrieb: > Note that C and LLVM types are *not* the same things (despite the > similar names). We are in the process of making this abundantly clear. > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless > integer quantities of specific sizes, regardless of platform). I had explicitly specified the size in the input code using a uint32_t type, the

Tony Pursell wrote: > On 17 Jun 2006 at 15:25, Philipp Klaus Krause wrote: > > >>Even though wine versions get released often and the weekly >>newsletters seem to report progress I get the impression that wine is >>not really improving. Of course it happens that some applications work >>with newer wine versions which didn't work with older ones, but at the

On Thu, 2006-11-23 at 21:09 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > > It generates C99. Its portability is no better or worse than any other > > backend. > > Does that mean that I will have to configure llvm as a cross-compiler > even when using the C backend? LLVM doesn't need to be configured as a cross compiler. It can generate code for a

Anton Korobeynikov schrieb: > Hello, Philipp. > >> unsigned is 16 bit on my target platform. > Could you please show LLVM bytecode? > I've attached the .bc file and the .c source and output files. I compiled dusing llvm-gcc (not configured as cross-compiler though, so that might be the problem). Nevertheless I don't really see why portable source shouldn't be

On Fri, 2006-11-24 at 21:13 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > Hmm the problem was a bit different. I just reproduced it. > > I used this input file: > > #include <stdint.h> > > uint32_t test(uint32_t t) > { > return(t + 42); > } > > and got the following code: > > unsigned test(unsigned ltmp_0_1) { > return

On 28/08/12 04:30, Philipp Klaus Krause wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only a C compiler exists? > Which use-cases do you have in mind for this backend? > Possibly yes, compiling C++ to C would require support for things

Hello people I'm studying worst case execution time calculation (WCET) and I'm planing use LLVM to develop a tool to calculate the maximum execution time of a real time program. Is there any project or initiative of using LLVM to real time systems and, specifically to calculate execution times? Does anyone have any hint? I'm reading the LLVM documentation and writing some test code