/opt/gcc/4.0-devel/bin/gcc -fpreprocessed parse.i -O2 -c pars e.i -v Reading specs from /opt/gcc/4.0-devel/lib/gcc/x86_64-suse-linux-gnu/4.0.0/specs Configured with: /cvs/gcc/configure --prefix=/opt/gcc/4.0-devel --disable-nls --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared--enable-languages=c,c++,treelang,java,f95,objc --with-system-zlib x86_64-suse-linux-gnu Thread model: posix gcc version 4.0.0 20041007 (experimental) /opt/gcc/4.0-devel/libexec/gcc/x86_64-suse-linux-gnu/4.0.0/cc1 -fpreprocessed parse.i -quiet -dumpbase parse.i -mtune=k8 -auxbase parse -O2 -version -fpreprocessed -o /tmp/ccnrYTh0.s GNU C version 4.0.0 20041007 (experimental) (x86_64-suse-linux-gnu) compiled by GNU C version 4.0.0 20041007 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 parse.i: In function 'ruby_yyparse': parse.i:13581: internal compiler error: tree check: expected function_decl, have continue_stmt in c_expand_body, at /c-decl.c:6328 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 7314 [details] Preprocessed source file (from x86-64)
I cannot reproduce this on powerpc-darwin but that does not mean it is not still a bug.
I cannot rreproduce this with a cross to x86_64-linux-gnu from powerpc-darwin so this is either wrong-code produced by the bootstrapping or a GC problem.
I see the ICE only on i586 and x86_64. ia64 and ppc compile this file fine. Do you want preprocessed i586 code?
Created attachment 7318 [details] Preprocessed source file - i386 compilation On i586 I get the same ICE - here's the preprocessed source file. Hope this helps.
Here's a reduced testcase: =========================== int foo() { unsigned char c; switch ((int)c) { case -1: case 0: case 4: case 5: case 42: return 0; } } =========================== parse.i: In function 'foo': parse.i:13: internal compiler error: tree check: expected function_decl, have error_mark in c_expand_body, at /c-decl.c:6334 Please submit a full bug report, [etc.] If I replace the 42 with 39 for example, I get a segfault instead. This might be related to PR 17657.
Note that I can reproduce it with a full bootstrap compiler but not with just stage 1 so something is causing wrong code somewhere.
Fixed by the same patch which fixed PR 17657.