similar to: [LLVMdev] llvm-gfortran gives errors on AMD64-Ubuntu

Hi, > I have installed llvm and llvm-gfortran on Pentium4 machine using 32-bit > Ubuntu, it works fine. I recently installed them on AMD64-Ubuntu 8.04, > llvm-gfortran gave me following errors > > $ llvm-gfortran -Wall hello.f95 -o hellof this works here on x86-64 ubuntu 8.10. I took a look in my libgfortran.a and it doesn't reference any of the symbols you mention. >

Hi Duncan, Thanks for your answers. Compiling .s file is OK after adding the -lgfortran -lgfortranbegin. I replace my Ubuntu 8.04 and by Ubuntu 8.10. And I checked all new packages installed by 'apt-get' are amd64 version. However after compiling the llvm-gfortran, I got the same error. Here is my configure arguments $ ../llvm-gcc4.2-2.3.source/configure --prefix=`pwd`/../install

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

Hi all, I am having a look at llvm-gfortran; it compiles OK, but I do not know how to using the JIT as described in http://llvm.org/docs/GettingStarted.html#tutorial. With llvm-gcc I managed to invoke the lli properly, but with llvm-gfortran compiled programs, it fails with the following message: philou at tleilax:~/gcc/llvm/install/bin$ lli ./main.bc 'main' function not found in

Hi, > Here is my configure arguments > $ ../llvm-gcc4.2-2.3.source/configure --prefix=`pwd`/../install > --program-prefix=llvm- \ > --disable-shared --disable-multilib \ > --enable-llvm=/llvm/llvm-obj --enable-languages=c,c++,fortran this looks ok to me. It's essentially the same as what I use. Try with 2.4 (about to be released). I'm not sure I ever tried to build the

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to

Anton, With regard to the gfortran test cases which don't fail on x86_64 Linux, these are the exact gfortran.log entries for them under i686 Darwin9... > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (internal compiler error) > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (test for excess errors) Executing on host:

Anton, Doh! It appears that *-*-darwin* is preset in configure to not build libgfortran... # APPLE LOCAL end ARM darwin target powerpc-*-darwin* | i[3456789]86-*-darwin*) noconfigdirs="$noconfigdirs bfd binutils ld gas opcodes gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" # LLVM LOCAL begin noconfigdirs="$noconfigdirs target-boehm-gc

Hello, Sorry for the late reply. Using dragonegg worked well, thanks all! Just as a note... I had to use llvm-ld during the link step because gfortran could not link bitcode. Here's an example of the error shown when using gfortran instead of llvm-ld: $ ${GCC_4_5_0}/bin/gfortran hw.f -c -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm -S $ ${LLVM_2_9}/bin/opt -mem2reg hw.o

Ashay, If I understand correctly, in hw.o you would have llvm bytecode, while linker expects regular object binary. Probably first you need to emit asm out of bytecode using llc? - D. 2011/9/12 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hello, > Sorry for the late reply. Using dragonegg worked well, thanks all! > Just as a note... I had to use llvm-ld during the link step

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

Thats correct. But using llc becomes a problem when I have archives (.a files). I could, in theory, extract its contents to a tempdir and then use llc and link but just wondering if there is a more elegant solution. Ashay On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Ashay, > > If I understand correctly, in hw.o you would have llvm

Hello > I am not very familiar with Fortran programs. I saw a few programs that had > a "MAIN" subroutine defined, some others that did not. Am I missing > something while compiling the code? Is there a different way to compile > bitcode (from Fortran programs) to a native binary? For Fortran MAIN is indeed something similar to C main, but not exactly the same. You have to

Sorry, at what step do you need archive? llc emits binary, it does not perform any linking, thus it does not need anything except the input bytecode file. Then during linking you can link whatever archives of binaries you want. 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Thats correct. But using llc becomes a problem when I have archives (.a > files). I could, in theory,

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

On 9/1/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > > On Fri, 1 Sep 2006, Michael McCracken wrote: [snip] > Now f951 doesn't crash when compiling, but still can't compile the > libgfortran files. It now finds some syntax errors in a generated file > that's part of the intrinsics

Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the

I see. And what's the purpose for outputting bitcode into *.o and *.a files? Do you want to perform an LLVM pass on linking step? 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hmm.. I didn't explain the problem completely last time. I am creating a > drop-in replacement for gcc and gfortran that runs an additional pass on the > bitcode before generating the native

No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13