gfortran: patch, question

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.

Right now, I can build f951 but it crashes while compiling the first
fortran file of libgfortran. I'm still working on it, but if the
following error and backtrace ring any bells for anyone, I'd
appreciate any tips.

/Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/gcc/gfortran
-B/Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/gcc/
-B/Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/../install/powerpc-apple-darwin8.6.0/bin/
-B/Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/../install/powerpc-apple-darwin8.6.0/lib/
-isystem /Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/../install/powerpc-apple-darwin8.6.0/include
-isystem /Users/mike/Documents/hpcl/LLVM/fortran/gcc4/obj/../install/powerpc-apple-darwin8.6.0/sys-include
-Wall -Wall -fno-repack-arrays -fno-underscoring -c
../../../src/libgfortran/intrinsics/selected_int_kind.f90 -fno-common
-DPIC -o .libs/selected_int_kind.o
../../../src/libgfortran/intrinsics/selected_int_kind.f90:0: internal
compiler error: in make_decl_rtl, at varasm.c:1018
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs&gt; for instructions.

(gdb) bt
#0 fancy_abort (file=0x5eecc8 "../../src/gcc/varasm.c", line=0,
function=0x41c1a680 "") at ../../src/gcc/diagnostic.c:587
#1 0x00275ab4 in make_decl_rtl (decl=0x5bb1dc) at ../../src/gcc/varasm.c:1018
#2 0x000555a0 in gfc_define_builtin (name=0x5eecc8
"../../src/gcc/varasm.c", type=0x3fa, code=0, library_name=0xffb59c52
<Address 0xffb59c52 out of bounds>, const_p=true) at
../../src/gcc/fortran/f95-lang.c:733
#3 0x00055760 in gfc_be_parse_file (set_yydebug=6221000) at
../../src/gcc/fortran/mathbuiltins.def:8
#4 0x002654cc in toplev_main (argc=1081721732, argv=0x407a2ee4) at
../../src/gcc/toplev.c:1105
#5 0x00002a74 in _start (argc=16, argv=0xbfffec50, envp=0xbfffec94)
at /SourceCache/Csu/Csu-58.1.1/crt.c:272
#6 0x0000291c in start ()

Thanks!
-mike

Index: gcc/fortran/Make-lang.in

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 make it as easy as possible to apply these, so
let me know any rules I should be following.

Don't worry about them. The rules for use are finicky and they are easy to add. I'll add them to any patches. Thanks!

Right now, I can build f951 but it crashes while compiling the first
fortran file of libgfortran. I'm still working on it, but if the
following error and backtrace ring any bells for anyone, I'd
appreciate any tips.

Ok

#0 fancy_abort (file=0x5eecc8 "../../src/gcc/varasm.c", line=0,
function=0x41c1a680 "") at ../../src/gcc/diagnostic.c:587
#1 0x00275ab4 in make_decl_rtl (decl=0x5bb1dc) at ../../src/gcc/varasm.c:1018
#2 0x000555a0 in gfc_define_builtin (name=0x5eecc8
"../../src/gcc/varasm.c", type=0x3fa, code=0, library_name=0xffb59c52
<Address 0xffb59c52 out of bounds>, const_p=true) at
../../src/gcc/fortran/f95-lang.c:733

This is crashing because make_decl_rtl is an RTL backend specific function. I haven't looked at the callsite but you probably want something like this:

#ifndef ENABLE_LLVM
     make_decl_rtl (olddecl);
#else
     make_decl_llvm (olddecl);
#endif

make_decl_rtl is also sometimes called implicitly by "DECL_RTL". Any uses of DECL_RTL need to be replaced with DECL_LLVM. If you have questions on a particular use, I'd be happy to help.

-Chris

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

Don't worry about them. The rules for use are finicky and they are easy
to add. I'll add them to any patches. Thanks!

OK, thanks - I'll just keep my patches clean and let you worry about
the markers.

[snip]

This is crashing because make_decl_rtl is an RTL backend specific
function. I haven't looked at the callsite but you probably want
something like this:

#ifndef ENABLE_LLVM
     make_decl_rtl (olddecl);
#else
     make_decl_llvm (olddecl);
#endif

make_decl_rtl is also sometimes called implicitly by "DECL_RTL". Any uses
of DECL_RTL need to be replaced with DECL_LLVM. If you have questions on
a particular use, I'd be happy to help.

OK, that makes sense. I should have been able to figure that out myself, huh :\
There are only a few cases of make_decl_rtl in the fortran code, so I
replaced them all as you suggested. It seemed straightforward in each
case.

I've attached a patch for the changes to the make_decl_rtl callsites,
at the end.

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 library.

It does compile a very simple test program. It generates
reasonable-looking LLVM code, except for using "MAIN__" instead of
"main" for the main procedure. I suspect that may be solved by
libgfortran once that's working. After editing that, the simple
example runs in lli up to the linking errors where the libgfortran
routines are called.

I'm looking into the errors, and I'll update the list on any progress.

Index: gcc/fortran/f95-lang.c

[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 library.

That was a problem with an incomplete build. libgfortran now compiles
without error (although not without warnings...).

I'm now testing on a couple of simple examples.
gfortran+llvm compiles my simplest example into native code correctly.
There are some issues with a more complicated example, but at least
this is a start.

I can generate llvm asm and bytecode using --emit-llvm -[S,c], but I
can't run the resulting files in lli. I am guessing that I would need
to compile libgfortran as bytecode and link it with llvm-link to get
that to work, right? I don't need to do that just yet, although I will
want to be able to run that way eventually.

I also noticed that there doesn't seem to be a test suite for gfortran
in the source distribution. I'm going to start with the updated
version of the NIST F77 test suite (updated to conform to F95) that's
available from fortran-2000.com.

Thanks,
-mike

I've attached a patch for the changes to the make_decl_rtl callsites,
at the end.

Sounds good, I'll apply the patch on monday.

-Chris

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 library.

It does compile a very simple test program. It generates
reasonable-looking LLVM code, except for using "MAIN__" instead of
"main" for the main procedure. I suspect that may be solved by
libgfortran once that's working. After editing that, the simple
example runs in lli up to the linking errors where the libgfortran
routines are called.

I'm looking into the errors, and I'll update the list on any progress.

Index: gcc/fortran/f95-lang.c

--- gcc/fortran/f95-lang.c (revision 160)
+++ gcc/fortran/f95-lang.c (working copy)
@@ -713,7 +713,11 @@
  TREE_PUBLIC (decl) = 1;
  if (library_name)
    SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name));
+#ifndef ENABLE_LLVM
  make_decl_rtl (decl);
+#else
+ make_decl_llvm (decl);
+#endif
  pushdecl (decl);
  DECL_BUILT_IN_CLASS (decl) = class;
  DECL_FUNCTION_CODE (decl) = function_code;
Index: gcc/fortran/trans-decl.c

--- gcc/fortran/trans-decl.c (revision 160)
+++ gcc/fortran/trans-decl.c (working copy)
@@ -1334,7 +1334,11 @@
    }

  /* Create RTL for function definition. */
+#ifndef ENABLE_LLVM
  make_decl_rtl (fndecl);
+#else
+ make_decl_llvm (fndecl);
+#endif

  init_function_start (fndecl);

@@ -2472,8 +2476,11 @@
  current_function_decl = fndecl;

  rest_of_decl_compilation (fndecl, 1, 0);
-
+#ifndef ENABLE_LLVM
  make_decl_rtl (fndecl);
+#else
+ make_decl_llvm (fndecl);
+#endif

  init_function_start (fndecl);

Thanks,
-mike

-Chris

I'm now testing on a couple of simple examples.
gfortran+llvm compiles my simplest example into native code correctly.
There are some issues with a more complicated example, but at least
this is a start.

Cool, you're making great progress.

I can generate llvm asm and bytecode using --emit-llvm -[S,c], but I
can't run the resulting files in lli. I am guessing that I would need
to compile libgfortran as bytecode and link it with llvm-link to get
that to work, right? I don't need to do that just yet, although I will
want to be able to run that way eventually.

If LLI is your goal, there are two possibilities: you can either compile the runtime library to .bc file which you statically llvm-link in, or you can compile it to a .so file, which you ask lli to load, like this:

$ lli -load myruntimelib.so myprogram.bc <args>

-Chris