Thanks.
While I have an easy repro, it's less easy to repro with any "onion peeling" or
logging.
For a while I was avoiding the problem via -enable-languages=c,c++.
This command is what fails (but not always)
/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/gcc/jc1.exe /src/gcc/libjava/
classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide-subr
outine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbas
e HTML_401F.class -mcpu=v9 -auxbase-strip gnu/javax/swing/text/html/parser/HTML_
401F.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fbootstrap-classes -fso
urce-filename=/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/sparc64-sun-sola
ris2.10/libjava/classpath/lib/classes -fbootclasspath=./:/src/gcc/libjava/classp
ath/lib/ -faux-classpath /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip -MD_ -MT gnu
/javax/swing/text/html/parser/HTML_401F.lo -MF gnu/javax/swing/text/html/parser/
HTML_401F.deps -o /d/DOCUME~1/jay/LOCALS~1/Temp/ccqOtWtu.s
output is:
GNU Java (GCC) version 4.3.1 (sparc64-sun-solaris2.10)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Class path starts here:
/d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip/ (zip)
./ (system)
/src/gcc/libjava/classpath/lib/ (system)
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In c
lass 'gnu.javax.swing.text.html.parser.HTML_401F':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In m
ethod 'gnu.javax.swing.text.html.parser.HTML_401F.defineElements()':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in
ternal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
and then here it is under a debugger:
Program received signal SIGSEGV, Segmentation fault.
0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
at /src/gcc/libiberty/hashtab.c:270
270 return htab_mod_1 (hash, p->prime, p->inv, p->shift);
(gdb) bt
#0 0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
at /src/gcc/libiberty/hashtab.c:270
#1 0x008fc752 in htab_find_slot_with_hash (htab=0x27b75c8, element=0x330a0,
hash=7818600, insert=INSERT) at /src/gcc/libiberty/hashtab.c:624
#2 0x008fc8fc in htab_find_slot (htab=0x27b75c8, element=0x330a0,
insert=INSERT) at /src/gcc/libiberty/hashtab.c:678
#3 0x006ce782 in get_def_blocks_for (var=0x3ba6b40)
at /src/gcc/gcc/tree-into-ssa.c:466
#4 0x006d2d78 in mark_use_interesting (var=0x3ba6b40, stmt=0x7c0ec6a0,
bb=0x79a11300, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2375
#5 0x006d2bb8 in prepare_block_for_update (bb=0x79a11300,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2448
#6 0x006d2cec in prepare_block_for_update (bb=0x79a11280,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#7 0x006d2cec in prepare_block_for_update (bb=0x79a111c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#8 0x006d2cec in prepare_block_for_update (bb=0x79a110c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9 0x006d2cec in prepare_block_for_update (bb=0x79a11040,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#10 0x006d2cec in prepare_block_for_update (bb=0x79a10f80,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#11 0x006d2cec in prepare_block_for_update (bb=0x79a10e80,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#12 0x006d2cec in prepare_block_for_update (bb=0x79a10e00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#13 0x006d2cec in prepare_block_for_update (bb=0x79a10d40,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#14 0x006d2cec in prepare_block_for_update (bb=0x79a10c40,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#15 0x006d2cec in prepare_block_for_update (bb=0x79a10bc0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#16 0x006d2cec in prepare_block_for_update (bb=0x79a10b00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#17 0x006d2cec in prepare_block_for_update (bb=0x79a10a00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#18 0x006d2cec in prepare_block_for_update (bb=0x79a10980,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#19 0x006d2cec in prepare_block_for_update (bb=0x79a108c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#20 0x006d2cec in prepare_block_for_update (bb=0x79a107c0,
...
... pages and pages ...
...
#9950 0x006d2cec in prepare_block_for_update (bb=0x7c82e7c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9951 0x006d2cec in prepare_block_for_update (bb=0x7c82e740,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9952 0x006d2cec in prepare_block_for_update (bb=0x7c82e6c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9953 0x006d2cec in prepare_block_for_update (bb=0x7c82e640,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9954 0x006d2cec in prepare_block_for_update (bb=0x7c82e5c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9955 0x006d4aa5 in update_ssa (update_flags=2048)
at /src/gcc/gcc/tree-into-ssa.c:3257
#9956 0x006c918f in compute_may_aliases ()
at /src/gcc/gcc/tree-ssa-alias.c:1897
#9957 0x004c7b42 in execute_function_todo (data=0x100001)
at /src/gcc/gcc/passes.c:913
#9958 0x004c78b8 in do_per_function (
callback=0x4c7a6b , data=0x100001)
at /src/gcc/gcc/passes.c:809
#9959 0x004c7d56 in execute_todo (flags=1048577) at /src/gcc/gcc/passes.c:993
#9960 0x004c811f in execute_one_pass (pass=0x9839f0)
at /src/gcc/gcc/passes.c:1144
#9961 0x004c81b1 in execute_pass_list (pass=0x9839f0)
at /src/gcc/gcc/passes.c:1175
#9962 0x004c81cd in execute_pass_list (pass=0x9837f0)
at /src/gcc/gcc/passes.c:1176
#9963 0x006c5129 in tree_rest_of_compilation (fndecl=0x7ef43200)
at /src/gcc/gcc/tree-optimize.c:404
#9964 0x0051baf9 in cgraph_expand_function (node=0x7ef64d08)
at /src/gcc/gcc/cgraphunit.c:1157
#9965 0x0051a972 in cgraph_assemble_pending_functions ()
at /src/gcc/gcc/cgraphunit.c:523
#9966 0x0051ac1e in cgraph_finalize_function (decl=0x7ef43200, nested=0 '\0')
at /src/gcc/gcc/cgraphunit.c:641
#9967 0x00411071 in finish_method (fndecl=0x7ef43200)
at /src/gcc/gcc/java/decl.c:1862
#9968 0x00410ec5 in end_java_method () at /src/gcc/gcc/java/decl.c:1810
#9969 0x0042fa0f in parse_class_file () at /src/gcc/gcc/java/jcf-parse.c:1698
#9970 0x0043039f in java_parse_file (set_yydebug=0)
at /src/gcc/gcc/java/jcf-parse.c:1986
#9971 0x0043ef44 in compile_file () at /src/gcc/gcc/toplev.c:1042
#9972 0x00440850 in do_compile () at /src/gcc/gcc/toplev.c:2240
#9973 0x004408b5 in toplev_main (argc=29, argv=0x2562088)
at /src/gcc/gcc/toplev.c:2272
#9974 0x0043dffa in main (argc=29, argv=0x2562088) at /src/gcc/gcc/main.c:35
I don't think the patch worked -- assuming I applied, built, ran it correctly.
From the callstack too, seems not likely.
If you really think so, I'll double check.
Personally I've been taught: "Don't use machine stack recursion, at least not
to a depth determined by user input." User will be able to blow your stack,
which is tricky but not impossible to recover from and report "out of memory".
Instead use recursion with a "manual heap based stack", or such. You know,
std::stack::push/pop.
Failure to heap allocate is a much simpler thing to detect and report, portably.
Granted, yes, I know, heap is much much much much slower than stack.
The PIC variant of the command always seems to succeed. Wierd?
Personally I think compiling non-PIC is a waste.
Compile everything twice? Yuck.
I wish Windows code was PIC, then wouldn't worry about base addresses and
the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g.
vtables).
- Jay
> Date: Sat, 26 Jul 2008 16:09:36 +0100
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]; gcc@gcc.gnu.org
> Subject: Re: gcj/sparc64?
>
> Tom Tromey wrote:
>>>>>>> "Jay" == Jay writes:
>>
>> Jay> This is an incomplete bug report.
>> Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree:
>> Jay> -bash-3.00$ gcc -v
>> Jay> Using built-in specs.
>> Jay> Target: sparc-sun-solaris2.10
>>
>> [...]
>> Jay> /.libs/HTML_401F.o
>> Jay> gcj: Internal error: Segmentation Fault (program jc1)
>> Jay> Please submit a full bug report.
>>
>> Knowing this particular file, maybe gcj just ran out of memory.
>> Anyway, please file in bugzilla. If you can include a jc1 stack
>> trace, that would be helpful.
>>
>> Jay> I shouldn't need this MAKEINFO=echo, but I do for some reason.
>> Jay> btw, it'd be cool if one could easily add languages later, remove
>> Jay> -disable-multilib later, etc. ie: "reconfigure slightly
>> Jay> differently/larger && make" and have it be super duper smart
>> Jay> about what to rebuild And -disable-libiconv would be nice.
>>
>> Send bug reports and/or patches...
>
> I know what this is. It's one of the optimization passes recursing too
> deeply and blowing the stack. It usually happens if the compiler has
> been built with -O0.
>
> Try this patch.
>
> Andrew.
>
>
> Index: tree-vrp.c
> ===================================================================
> --- tree-vrp.c (revision 136670)
> +++ tree-vrp.c (working copy)
> @@ -4049,6 +4049,8 @@
> the predicate operands, an assert location node is added to the
> list of assertions for the corresponding operands. */
>
> +static size_t depth;
> +
> static bool
> find_conditional_asserts (basic_block bb, tree last)
> {
> @@ -4062,6 +4064,10 @@
> need_assert = false;
> bsi = bsi_for_stmt (last);
>
> + depth++;
> + if (depth> 500)
> + goto ret;
> +
> /* Look for uses of the operands in each of the sub-graphs
> rooted at BB. We need to check each of the outgoing edges
> separately, so that we know what kind of ASSERT_EXPR to
> @@ -4121,6 +4127,8 @@
> FOR_EACH_SSA_TREE_OPERAND (op, last, iter, SSA_OP_USE)
> SET_BIT (found_in_subgraph, SSA_NAME_VERSION (op));
>
> + ret:
> + depth--;
> return need_assert;
> }
>
