similar to: [LLVMdev] Where can llvm users discuss llvm?

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,

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

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 >

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

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

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

I am sure this has been asked before, but why not use Google newsgroup or at least some forum BBS software instead of this cumbersome mailing list process? -- Costas Menico Meezon Software Corp 201-224-8111 costas@meezon.com --

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

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

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

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,

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: > 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

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

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

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

Reid Spencer schrieb: > hat you do need to do > is configure your front end to be a cross compiler. Then it will > generate the correct LLVM input for that platform (and consequently LLVM > will generate code for that platform) regardless of the platform on > which either LLVM or your front end are running. > Is that needed for thing like sizeof() and size of native datatypes

On 27.08.2012 22:56, Roel Jordans wrote: > > Anyway, that brings to my final question: Which features are > critical/important/wanted/unwanted for a C back-end? > I'd like it to be easy to configure (e.g. to tell which size int is assumed to have). I'd prefer the resulting code to not rely on implementation-defined behaviour (e.g. not make any assumptions about the size of

I tried llvm-gcc -c test.c llvm-gcc test.o llc -march=c test.bc -f -o test2.c Then I compiled both test.c and test2.c with sdcc, a compiler which lacks high-level optimization. The code generated from test2.c was bigger. Then I tried llvm-gcc -O5 -Os -c test.c llvm-gcc -O5 -Os test.o llc -march=c test.bc -f -o test2.c But it generated exactly the same code as the commands above. What is it that