When building libgcj for gcj m68k cross compiler the compiler segmentation faults on java.lang.Character.java == Host== $ uname -a CYGWIN_NT-5.1 RICHO 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin == Program which causes errors== public final class Character { public static final String[] error = { " 0", " 1", " 2", " 3", " 4", " 5", " 6", " 7", " 8", " 9", "10", "11", "12", "13", "14" }; } == command line == /home/john/gnu/build/m68k-coff-test/gcc/gcc/gcj -v -da -Q -save-temps - B/home/john/gnu/build/m68k-coff-test/gcc/gcc/ -B/home/john/H-i686-pc- cygwin/m68k-coff-test/bin/ -B/home/john/H-i686-pc-cygwin/m68k-coff/lib/ - isystem /home/john/H-i686-pc-cygwin/m68k-coff/include --encoding=UTF-8 - fclasspath= -fbootclasspath=/home/john/gnu/build/m68k-coff-test/gcc/m68k- coff/libjava -g -O0 -c Character.java -o Character.o Reading specs from /home/john/gnu/build/m68k-coff-test/gcc/gcc/specs Reading specs from libgcj.spec rename spec lib to liborig Configured with: /home/john/gnu/gcc-3.3/configure -v --prefix=/home/john/H- i686-pc-cygwin --target=m68k-coff --enable-checking --enable- languages=c,c++,java --disable-multilib --disable-java-net --with-newlib Thread model: single gcc version 3.3 /home/john/gnu/build/m68k-coff-test/gcc/gcc/jc1.exe Character.java -fuse- divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions - dumpbaseCharacter.java -da -auxbase-strip Character.o -g -O0 -version - fencoding=UTF-8 -fclasspath= -fbootclasspath=/home/john/gnu/build/m68k-coff- test/gcc/m68k-coff/libjava -o Character.s GNU Java version 3.3 (m68k-coff) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32678 options passed: -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -auxbase-strip -g -O0 -fencoding=UTF-8 -fclasspath= -fbootclasspath=/home/john/gnu/build/m68k-coff-test/gcc/m68k-coff/libjava options enabled: -fpeephole -ffunction-cse -fkeep-inline-functions -fkeep-static-consts -freg-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec -fbranch-count-reg -fexceptions -funwind-tables -fasynchronous-unwind-tables -fnon-call-exceptions -fcommon -fgnu-linker -fargument-alias -fzero-initialized-in-bss -fident -fmath-errno -fbounds-check -m68020 -mc68020 -mbitfield -m68881 -m68030 -m68332 -mcpu32 Class path starts here: ./ /home/john/gnu/build/m68k-coff-test/gcc/m68k-coff/libjava/ (system) class Character class java.lang.String class java.lang.Object interface java.lang.CharSequence interface java.lang.Comparable interface java.io.Serializable cl ass java.lang.String$CaseInsensitiveComparator interface java.util.Comparator [Character. ()] [Character. <clinit>()]Character.java: In class `Character': Character.java: In method `<clinit>()': Character.java:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. == gdb output of jc1 run This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /home/john/gnu/build/m68k-coff-test/gcc/gcc/jc1.exe Character. java -g0 -O0 -fclasspath= -fbootclasspath=/home/john/gnu/build/m68k-coff- test/gc c/m68k-coff/libjava -o Character.s class Character class java.lang.String class java.lang.Object interface java.la ng.CharSequence interface java.lang.Comparable interface java.io.Serializable cl ass java.lang.String$CaseInsensitiveComparator interface java.util.Comparator [C haracter. ()] [Character. <clinit>()] Program received signal SIGSEGV, Segmentation fault. 0x00531020 in emit_block_move_via_libcall (dst=0x12a2f60, src=0x12a2f90, size=0x 12703f0) at /home/john/gnu/gcc-3.3/gcc/expr.c:1933 1933 size_mode = TYPE_MODE (unsigned_type_node); (gdb) list 1928 src = copy_to_mode_reg (Pmode, XEXP (src, 0)); 1929 1930 if (TARGET_MEM_FUNCTIONS) 1931 size_mode = TYPE_MODE (sizetype); 1932 else 1933 size_mode = TYPE_MODE (unsigned_type_node); 1934 size = convert_to_mode (size_mode, size, 1); 1935 size = copy_to_mode_reg (size_mode, size); 1936 1937 /* It is incorrect to use the libcall calling conventions to call (gdb) where #0 0x00531020 in emit_block_move_via_libcall (dst=0x12a2f60, src=0x12a2f90, siz e=0x12703f0) at /home/john/gnu/gcc-3.3/gcc/expr.c:1933 #1 0x00530d28 in emit_block_move (x=0x12a2f40, y=0x12a2f50, size=0x12703f0, met hod=BLOCK_OP_NORMAL) at /home/john/gnu/gcc-3.3/gcc/expr.c:1756 #2 0x00537959 in store_expr (exp=0x128f6d8, target=0x12a2950, want_value=0) at /home/john/gnu/gcc-3.3/gcc/expr.c:4619 #3 0x0053b77c in store_field (target=0x12a2930, bitsize=480, bitpos=96, mode=BL Kmode, exp=0x128f6d8, value_mode=VOIDmode, unsignedp=0, type=0x12bb0e0, alias_se t=0) at /home/john/gnu/gcc-3.3/gcc/expr.c:5618 #4 0x00535cab in expand_assignment (to=0x12bc288, from=0x128f6d8, want_value=0, suggest_reg=0) at /home/john/gnu/gcc-3.3/gcc/expr.c:4128 #5 0x0049bb2d in java_expand_expr (exp=0x128f6f0, target=0x12a25f0, tmode=SImod e, modifier=0) at /home/john/gnu/gcc-3.3/gcc/java/expr.c:2573 #6 0x00554d0e in expand_expr (exp=0x128f6f0, target=0x12a25f0, tmode=SImode, mo difier=EXPAND_NORMAL) at /home/john/gnu/gcc-3.3/gcc/expr.c:9392 #7 0x005368cb in store_expr (exp=0x128f6f0, target=0x12a25f0, want_value=1) at /home/john/gnu/gcc-3.3/gcc/expr.c:4379 #8 0x0053629e in expand_assignment (to=0x12a1620, from=0x128f6f0, want_value=1, suggest_reg=0) at /home/john/gnu/gcc-3.3/gcc/expr.c:4252 #9 0x00552bf0 in expand_expr (exp=0x128f708, target=0x0, tmode=VOIDmode, modifi er=EXPAND_NORMAL) at /home/john/gnu/gcc-3.3/gcc/expr.c:9031 #10 0x00541706 in expand_expr (exp=0x12ba2e0, target=0x0, tmode=VOIDmode, modifi er=EXPAND_NORMAL) at /home/john/gnu/gcc-3.3/gcc/expr.c:6831 #11 0x0049bedb in java_expand_expr (exp=0x12b8360, target=0x1270210, tmode=VOIDm ode, modifier=0) at /home/john/gnu/gcc-3.3/gcc/java/expr.c:2617 #12 0x00554d0e in expand_expr (exp=0x12b8360, target=0x0, tmode=VOIDmode, modifi er=EXPAND_NORMAL) at /home/john/gnu/gcc-3.3/gcc/expr.c:9392 #13 0x005ef75a in expand_expr_stmt_value (exp=0x12b8360, want_value=0, maybe_las t=1) at /home/john/gnu/gcc-3.3/gcc/stmt.c:2184 #14 0x005ef5ec in expand_expr_stmt (exp=0x12b8360) at /home/john/gnu/gcc- 3.3/gcc /stmt.c:2138 #15 0x00439c6f in source_end_java_method () at /home/mitchell/gcc-3.3/gcc- 3.3/gc c/java/parse.y:7506 #16 0x0043cfad in java_expand_method_bodies (class=0x12a1460) at /home/mitchell/ gcc-3.3/gcc-3.3/gcc/java/parse.y:8203 #17 0x0044212b in java_expand_classes () at /home/mitchell/gcc-3.3/gcc- 3.3/gcc/j ava/parse.y:9184 #18 0x004bb3bc in java_parse_file (set_yydebug=0) at /home/john/gnu/gcc- 3.3/gcc/ java/jcf-parse.c:1144 #19 0x004e333a in compile_file () at /home/john/gnu/gcc-3.3/gcc/toplev.c:2130 #20 0x004ea749 in do_compile () at /home/john/gnu/gcc-3.3/gcc/toplev.c:5370 #21 0x004ea79f in toplev_main (argc=8, argv=0x101126e0) at /home/john/gnu/gcc- 3. 3/gcc/toplev.c:5400 #22 0x004dacf0 in main (argc=8, argv=0x101126e0) at /home/john/gnu/gcc- 3.3/gcc/m ain.c:35 (gdb)
The problem was also found in the cvs version. The problem is that the two tree nodes (unsigned_type_node and const_ptr_type_node) needed by emit_block_move_via_libcall (in expr.c) are not created in java/decl.c. These nodes appear to be used when generating a memcpy or bcopy on CPUs which do not have block/string move instructions, as is the case with the m68k. Adding the following two lines seems to fix the problem decl.c 485a unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE); const_ptr_type_node = build_pointer_type (build_type_variant (void_type_node, 1, 0));
Actually I think it is the other way around in that emit_block_move_via_libcall should not use unsigned_type_node nor const_ptr_type_node because they are only C types and not generic types. This is like the same assumptions that are made by -fprofile-arcs (bug 8260) which cause it to fail also.
Actually I am wrong, the Java front-end should be initializing these nodes.
Defining these types seems ok to me. It would be nice if there were front end documentation explaining that front ends are required to, though. FWIW Alexandre Oliva has a patch to bug 8620 the "other way" -- by changing gcc, not gcj.
expr.c no longer uses unsigned_type_node, and java/decl.c now initializes const_ptr_type_node.