$ llvm-gcc 025.c -c -o 025 025.c:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct poll_table_entry’ 025.c:1: warning: division by zero 025.c:1: error: array type has incomplete element type 025.c:1: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in grokdeclarator, at c-decl.c:4356 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions. $ cat 025.c struct poll_table_entry inline_entries[((832 - 256) / sizeof(struct poll_table_entry))]; $
Hi Nick, Which version of llvm-gcc are you using? It doesn't ICE on this version: [Gaz:llvm] llvm-gcc --version llvm-gcc (GCC) 3.4-llvm 20051104 (LLVM 1.7cvs) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ llvm-gcc --version llvm-gcc (GCC) 4.0.1 LLVM (Apple Computer, Inc. build 5400) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Latest out of the subversion repository last night.
I'll take a look tomorrow unless someone beats me to it.
This appears to be a problem with the generic GCC code llvm-gcc is based on.
Merged some code from mainline GCC to c-decl.c. Essentially, if there is an array with an incomplete type, it sets the type to an error type. But then we were trying to do things with that type. Submitted a fix for this to the llvmdev mailing list.
A quick test with the gcc 4.0.1 compiler on a Mac Intel machine (without the apple local patches) and it doesn't ICE.
I can verify that this patch works on my x86-linux build, and still passes dejagnu's frontend tests. The patch itself looks minimal to me (though I'm no gcc hacker). I think it should be applied. Chris?
Mystery Of The Kind-of Working Compiler! Here's what's happening. In LLVM's GCC, the crashing line resolves to this after preprocessing: if (size_varies) (__extension__ ({ const tree __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)- >common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "../../llvm-\ gcc4/gcc/c-decl.c", 4358, __FUNCTION__); __t; })->type.lang_flag_1) = 1; With TOT in positron, it comes out as: if (size_varies) ((type)->type.lang_flag_1) = 1; So, basically, when tree checking is enabled, we get the ICE. Otherwise, it goes away.
Ahh, so this fails with a non-llvm checking-enabled positron compiler as well? -Chris
That's my next check. :-) I'll generate the new compiler now and make sure that the failure's there too.
Holy crap! When "--enable-checking" is used during configuration with non-LLVM gcc, we get the same ICE. Hott! I'll submit the patch.
Whoa, that even makes sense! :) Thanks Bill, -Chris
Fixed: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060918/038091.html Also patched llvm-gcc.
Thanks Bill!