similar to: [LLVMdev] gfortran: link error building gfortran on linux

The curent llvm svn (r54623) is unable to link the gfortran compiler in llvm-gcc-4.2 svn. I am getting the error... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

Hi, in a thread this afternoon about compiling the Fortran SPEC2000 to LLVM bytecode, Chris mentioned that it should be possible to compile to LLVM with the gfortran front end, although no one has necessarily tried it. I was surprised (and happy) to hear this, as under the impression that it would require a "complete rewrite of the gfortran backend" [1]. Now, I probably misinterpreted

Hi Jack, > The curent llvm svn (r54623) is unable to link the gfortran > compiler in llvm-gcc-4.2 svn. I am getting the error... ... > Undefined symbols: > "_create_init_utf16_var", referenced from: > _darwin_build_constant_cfstring in libbackend.a(darwin.o) this is probably due to recent Apple changes. Fortran builds on linux. > Why is c++ being used

This is OS X 10.6. I can build llvm-gcc and llvm-g++ just fine, but the gfortran front end cannot find a symbol. Where would it normally be defined ? ==================================================================== /Developer/usr/bin/g++-4.2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros

Does anyone know if the issue with building the gfortran front-end on Darwin will be addressed for llvm 2.4? The last time a checked a few weeks back, llvm-gcc-4.2 svn was still producing the linkage error... > Undefined symbols: > "_create_init_utf16_var", referenced from: > _darwin_build_constant_cfstring in libbackend.a(darwin.o) I believe the analysis of this was

Another option might be g95 instead of gfortran. I haven't used it for a while, but I seem to recall it working fine in gcc 4.0.1. On 9/11/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/9/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > > On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > > > On 9/9/06, Chris

On 9/9/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > > On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > > > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > > > You wrote: > > > >> The NIST F77 test suite doesn't seem to be compatible with

On 9/9/06, Steven Bosscher <stevenb.gcc at gmail.com> wrote: > On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > > You wrote: > > >> The NIST F77 test suite doesn't seem to be compatible with gfortran at > > >> all, > > > Actually, the entire suite compiles flawlessly with

On Wed, 30 Aug 2006, Michael McCracken wrote: > Hi, in a thread this afternoon about compiling the Fortran SPEC2000 to > LLVM bytecode, Chris mentioned that it should be possible to compile > to LLVM with the gfortran front end, although no one has necessarily > tried it. Yup. > I was surprised (and happy) to hear this, as under the impression that > it would require a

IMHO, this is one of my biggest concerns about Apple eventually switching over to llvm-gcc. The absence of the rigorous patch review process required in FSF gcc will tend to allow these sort of issues to slip by. Jack On Tue, Aug 12, 2008 at 09:05:11PM -0700, Bill Wendling wrote: > On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote: > >> Hi Jack, >> >>>

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

On 9/6/06, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 5 Sep 2006, Michael McCracken wrote: [snip] > > ../../src/gcc/llvm-convert.cpp:3871: failed assertion > > `(TREE_CONSTANT(exp) || TREE_CODE(exp) == STRING_CST) && "Isn't a > > constant!"' > > > > In this case, TreeConstantToLLVM::Convert() is getting a constant to >

On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote: > Hi Jack, > >> The curent llvm svn (r54623) is unable to link the gfortran >> compiler in llvm-gcc-4.2 svn. I am getting the error... > ... >> Undefined symbols: >> "_create_init_utf16_var", referenced from: >> _darwin_build_constant_cfstring in libbackend.a(darwin.o) > > this is

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

On 9/9/06, Chris Lattner <sabre at nondot.org> wrote: > On Sat, 9 Sep 2006, Steven Bosscher wrote: > > You wrote: > >> The NIST F77 test suite doesn't seem to be compatible with gfortran at > >> all, > > Actually, the entire suite compiles flawlessly with gfortran. > > See http://gcc.gnu.org/wiki/GFortranResults > > Was that true of GCC 4.0.1?

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 x86-64 linux, in stage 2, I get: c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o

Duncan, Actually, shouldn't this be just an error in the Makefile.in or Makefile.am? Why should a link line like... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

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

On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: > On x86-64 linux, in stage 2, I get: > > c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o f951 \ > fortran/arith.o