try to compile this: /* all this is from javaprims.h */ #pragma GCC java_exceptions extern "Java" { typedef __java_byte jbyte; typedef __java_short jshort; typedef __java_int jint; typedef __java_long jlong; typedef __java_float jfloat; typedef __java_double jdouble; typedef __java_char jchar; typedef __java_boolean jboolean; typedef jint jsize; namespace java { namespace lang { class Class; } } typedef class java::lang::Class* jclass; /* up to here */ static void foo () { new jboolean[1]; } You will get prnew.cc: In function `void foo()': prnew.cc:26: internal compiler error: can't find class$ Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. See bug 4439 for bug was first published. Should this be in c++ or java?
Here's a smaller testcase: --------------------------- typedef int* jclass; void foo () { new __java_boolean; } --------------------------- g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc x.cc: In function `void foo()': x.cc:4: internal compiler error: can't find class$ Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. There's obviously a lot of magic going on behind the scenes since removing the (unused) typedef makes something entirely different happen. With 2.95 we get on above code snippet g/x> c++ -c x.cc x.cc: In function `void foo()': x.cc:4: call to Java constructor, while `_Jv_AllocObject' undefined That's still an error, but not an ICE. The present behavior (existing since 3.0) is thus a regression. As to the cause of the ICE: here's a backtrace #0 build_java_class_ref (type=0x0) at ../../gcc-3.4-CVS/gcc/cp/init.c:2105 #1 0x0812b6d9 in build_new_1 (exp=0x0) at ../../gcc-3.4-CVS/gcc/cp/init.c:2255 #2 0x0812a332 in build_new (placement=0x0, decl=0x0, init=0x0, use_global_new=0) at ../../gcc-3.4-CVS/gcc/cp/init.c:2064 #3 0x080faa74 in cp_parser_new_expression (parser=0x401a9fc0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4574 #4 0x080fa7fc in cp_parser_unary_expression (parser=0x401a9fc0, address_p=false) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4413 #5 0x080fb08c in cp_parser_pm_expression (parser=0x401a9fc0) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4939 #6 0x08104282 in cp_parser_binary_expression (parser=0x401a9fc0, token_tree_map=0x8478c00, fn=0x80fb070 <cp_parser_pm_expression>) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13544 #7 0x080fb131 in cp_parser_multiplicative_expression (parser=0x6) at ../../gcc-3.4-CVS/gcc/cp/parser.c:4993 #8 0x08104282 in cp_parser_binary_expression (parser=0x401a9fc0, token_tree_map=0x8478c20, fn=0x80fb110 <cp_parser_multiplicative_expression>) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13544 #9 0x080fb161 in cp_parser_additive_expression (parser=0x6) at ../../gcc-3.4-CVS/gcc/cp/parser.c:5016 #10 0x08104282 in cp_parser_binary_expression (parser=0x401a9fc0, token_tree_map=0x8478c38, fn=0x80fb140 <cp_parser_additive_expression>) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13544 ... Note that type=0x0 on entry of the function. That doesn't make much sense, though, since the function is called here /* Allocate the object. */ if (! placement && TYPE_FOR_JAVA (true_type)) { tree class_addr, alloc_decl; tree class_decl = build_java_class_ref (true_type); and in frame 1 I see (gdb) up #1 0x0812b6d9 in build_new_1 (exp=0x0) at ../../gcc-3.4-CVS/gcc/cp/init.c:2255 (gdb) p true_type $5 = 0x4018a438 That's inconsistent, or my debugger is broken. May someone else make sense out of that. W.
You're debugging GCC compiled with optimization turned on. I debug GCC by 'touch cp/cp-tree.h' and rebuilding my cc1plus using the script below. You can also take it from Makefile with -O2 replaced by -O0. make CC='stage2/xgcc -Bstage2/ -B/opt/gcc-snapshot/i586-pc-linux-gnu/bin/' \ CFLAGS='-W -Wall -g -O0' LDFLAGS= \ libdir=/opt/gcc-snapshot/lib STAGE_PREFIX=stage1/ LANGUAGES='c c++'
An ice-on-invalid is not P1/critical.
Not really a regression as the ICE should not really be an ICE but just an error.
I get a different ICE now on the mainline: pr11006.cc: In function `void foo()': pr11006.cc:4: internal compiler error: tree check: expected record_type, union_type or qual_union_type; have integer_type in build_java_class_ref, at cp/init.c:1868 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
The ICE internal compiler error: can't find class$ has been fixed on mainline (see PR 11468), but the ICE mentioned in commment #5 is still present.
Original test case and test case from comment #1 both give this result (i.e. no ICE) for me: (Comment #1) <stdin>: In function ‘void foo()’: <stdin>:4: error: can't find ‘class$’ in ‘__java_boolean’ (Original test case) <stdin>: In function ‘void foo()’: <stdin>:28: error: can't find ‘class$’ in ‘jboolean’ (c++ --version gives c++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2)
This only ICEs now with checking turned on: t.cc: In function 'void foo()': t.cc:28: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in build_java_class_ref, at cp/init.c:2426 Without checking turned on I get the following ICE: t.cc: In function 'void foo()': t.cc:28: error: can't find 'class$' in 'jboolean' t.cc: At global scope: t.cc:29: error: expected `}' at end of input
Author: paolo Date: Wed Nov 6 20:19:10 2013 New Revision: 204469 URL: http://gcc.gnu.org/viewcvs?rev=204469&root=gcc&view=rev Log: /cp 2013-11-06 Paolo Carlini <paolo.carlini@oracle.com> PR c++/11006 * init.c (build_new_1): Don't call build_java_class_ref on non-class types. /testsuite 2013-11-06 Paolo Carlini <paolo.carlini@oracle.com> PR c++/11006 * g++.dg/other/java3.C: New. Added: trunk/gcc/testsuite/g++.dg/other/java3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
Fixed.