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> 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
==================================================================---
gcc/fortran/Make-lang.in (revision 160)
+++ gcc/fortran/Make-lang.in (working copy)
@@ -106,7 +106,7 @@
# The compiler itself is called f951.
f951$(exeext): $(F95_OBJS) \
$(BACKEND) $(LIBDEPS)
- $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
+ $(LINKCC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
$(F95_OBJS) $(BACKEND) $(F95_LIBS)
gt-fortran-f95-lang.h gtype-fortran.h : s-gtype; @true
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
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 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:733This 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 -- http://nondot.org/sabre/ http://llvm.org/
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 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 ==================================================================--- 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 -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/
Possibly Parallel Threads
- [LLVMdev] gfortran: patch, question
- [LLVMdev] gfortran: patch, question
- [LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
- [LLVMdev] gfortran: array constructor problems