similar to: [LLVMdev] llvm-gcc and -emit-llvm

On Jun 9, 2008, at 11:32 AM, Jonathan Turner wrote: > Just thought I'd mention this to keep other people from stubbing > their toes on it... > > Using llvm-gcc/llvm-g++ and -emit-llvm, you need to make sure to > pass -S as well, like so: > > ./llvm-g++ -S -emit-llvm hello.cpp > > not: /llvm-g++ -emit-llvm hello.cpp > > I'm sure that's old news to

I'm interested in cleaning up the documentation for this, but it is in 4 different formats. From the makefile it looks like the .pod is the master. Do I need to do anything special after changing this to get it propagated elsewhere? On Jun 9, 2008, at 12:52 PMPDT, Dale Johannesen wrote: > On Jun 9, 2008, at 11:32 AM, Jonathan Turner wrote: >> Just thought I'd mention this

On Monday 09 June 2008 14:52, Dale Johannesen wrote: > It seems clear the current interface can be confusing; you are not the > first. Perhaps -emit-llvm should be renamed to indicate it does not > necessarily result in emitting llvm IR? > -output-format-llvm? Seems pretty ugly, maybe someone can do better. -mcpu=llvm? Yes, it may require some mucking around with config files, but

This is just a slight modification of a question I asked earlier. Thanks to all the responders. I have a data set(Bill) of with 1 variable (var1), with 100 obs that are in ascending order. I want to sample every 10 observations and save them in 10 different groups such as Group1 is obs 1-10 Group 2 is obs-11-20 .... Subset data into the 10 groups, then calculate the mean/0.8 of var1 for each

On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: >> Result compiled with llvm-g++ 2.0: >> tan float: -2.18504 >> tan double: 0.309336 > > This may be due to bug 1505. It fails on x86 using x87 floating point, with the inliner not run, because of 1505, yes. Gonsolo, is that your situation? (What happens is, there is a wrapper in the header file for std::tan (float),

Dale Johannesen schrieb: > On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach wrote: >> No matter if I try " >> llvm-g++ a.cpp -c -emit-llvm >> " with "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" on Windows XP >> or if I am trying it on Ubuntu... >> >> Only the a.o file will be created without any error messages. The .bc >>

Recently I've been working on putting a little language together using the llvm toolset. I think I've wrapped my head around some of the beginner bits (and a big "thank you" for the kaleidoscope tutorial). What I'd like to do now is to take my Module* and output either a C file for native compilation, or just directly output a native binary. I saw that llc can output C

Eli Friedman schrieb: > On Wed, Sep 17, 2008 at 1:31 PM, Michael Reichenbach > <michael_reichenbach at freenet.de> wrote: >> question about: >> http://llvm.org/docs/FAQ.html#translatec++ >> "With llvm-gcc3, this will generate program and program.bc." >> >> Is this llvm-gcc3 only out of date of is it really only llvm-gcc3? > > Those

Hello Michael, If you're just trying to run the code you can skip the llc and gcc states and go directly to lli. PowerPC and Intel x86 are the only architectures supported by the jit compiler right now but it should work fine from Windows. The C output backend needs some work since C isn't a low-level language enough to compile the abstractions of LLVM Assembly code. --Sam Crow --- On

On Sep 17, 2008, at 2:36 PMPDT, Michael Reichenbach wrote: > > No matter if I try " > llvm-g++ a.cpp -c -emit-llvm > " with "LLVM-GCC 4.2 Front End Binaries for Mingw32/x86" on Windows XP > or if I am trying it on Ubuntu... > > Only the a.o file will be created without any error messages. The .bc > file will not be created, do you know why? -emit-llvm

On Jun 10, 2008, at 3:34 PM, Dale Johannesen wrote: > I'm interested in cleaning up the documentation for this, but it is in > 4 different formats. > From the makefile it looks like the .pod is the master. Do I need to > do anything special > after changing this to get it propagated elsewhere? Nope, editing and committing the .pod file should be enough, thanks Dale! -Chris

Hello, I would like to ask the llvm developers to have a look at http:// llvm.org/bugs/show_bug.cgi?id=918 . This bug has been reported 4 month ago but is none the less a somewhat serious one. Below I have pasted the test case and output of the issue running on my ppc machine. thank you Eric pb:~ eric$ cat testme.ll;llvm-as -f testme.ll;llc -march=c -f testme.bc;gcc -c testme.cbe.c

Hi Dale, Thanks for getting back. I may not be able to switch to llvm 4.2 at this time. I did try: llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc llc -march=ppc32 sumarray.bc gcc -arch ppc sumarray.s And this produced a ppc binary that worked (at least in this case). Do you know if this approach is worthwhile? Thx, Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at

On Feb 26, 2009, at 10:16 AMPST, Brice Lin wrote: > Is it possible to add any flags to this command so that the resulting > compile runs perfectly fine (-c builds, but does not work)? > > llvm-gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized > -Wsign-compare -Wno-pointer-sign -Wformat-security -fno-builtin-memset > -emit-llvm <filename.c> > > where

Is it possible to add any flags to this command so that the resulting compile runs perfectly fine (-c builds, but does not work)? llvm-gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -Wformat-security -fno-builtin-memset -emit-llvm <filename.c> where <filename.c> contains #include <stdio.h> int main() { exit(0); } Thanks

Eric van Riet Paap wrote: > *testme.cbe.c:106: error: array type has incomplete element type* The problem code boils down to: /* Structure forward decls */ struct l_structtype_s; /* Typedefs */ typedef struct l_structtype_s l_fixarray_array3[3]; which is illegal C, but perfectly valid C++, and g++ accepts it. The structure contents are defined right afterwards, but I assume that

I've read that LLVM can convert from C++ to C code. So I've used it in such a way: I'm Windows-user so I used MinGW. I employed this file as the test: llvm-hello.cpp: #include <iostream> int main(int argc, char* argv[]) { system("pause"); return 0; } result of "llvm-g++ C:\llvm_hello.cpp -o C:\llvm_hellopp.exe" worked just fine. as a result of

On Mar 16, 2008, at 5:07 AM, Duncan Sands wrote: >> Did anything ever come of the work on exception handling for x86_64? >> >> I'm having problems with exceptions on linux x86_64. > > I'm fairly sure that exception handling doesn't currently work on > x86-64 linux (it may work with darwin - not sure). I don't know > what it would take to get it to

On Jan 29, 2010, at 2:55 PMPST, Jose Rangel wrote: > Hi Dale, > > Thanks for getting back. I may not be able to switch to llvm 4.2 at > this > time. I did try: > > llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc > llc -march=ppc32 sumarray.bc > gcc -arch ppc sumarray.s > > And this produced a ppc binary that worked (at least in this case). > > Do you

Does llvm-gcc do more, less, or the same amount of function inlining as gcc? What about llvm-g++ and g++? I am specifically interested in inlining that occurs when I run with the --emit-llvm command line flag like this: llvm-gcc -c --emit-llvm foo.c thus generating bitcode. That is, I am not interested at this moment in what happens when I run the opt or llc tools on the bit code after its