The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch. A reduced testcase is: ======================= typedef struct A B; int i = sizeof(B); ======================= bug.c:2: error: invalid application of `sizeof' to incomplete type ` Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, [etc.] The culprit is the code in c-objc-common.c (c_tree_printer) <case 'T'>: case 'T': if (TREE_CODE (t) == TYPE_DECL) { if (DECL_NAME (t)) n = (*lang_hooks.decl_printable_name) (t, 2); } else { t = TYPE_NAME (t); if (t) n = IDENTIFIER_POINTER (t); } break; In the above case t is a RECORD_TYPE, but TYPE_NAME (t) is a TYPE_DECL. So there's some logic missing to handle this case. The other problem is that the testcase in the testsuite PASSed despite the ICE. The comment on top of the testcase says: /* This test case contains a large number of syntactic errors. We believe the intent of the test is that the compiler simply not crash. The set of error messages reported is different when the C parser is generated with bison 1.50 than 1.35. It is not worth attempting to prevent this. Instead, we use a single dg-error with a regexp that will match _all_ the errors indiscriminately. The old error/warning/etc markers are kept around for reference, but disabled. Revisit after new (recursive descent) parser is implemented for C. -- zw 2002-10-17 */ /* { dg-error ".*" "many syntax errors" { target *-*-* } 0 } */ Well, the regexp also matches the ICE-message, so the testcase is now broken. While this is probably hard to fix in 3.4 and 4.0, the testcase be revisited on mainline and the 4.1 branch where the new C parser is in place. I'll file a new PR for this.
The PR for the testcase in the testsuite is PR 25302.
Subject: Re: New: [3.4 regression] ICE for sizofe of incomplete type "reichelt at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch. | A reduced testcase is: | | ======================= | typedef struct A B; | int i = sizeof(B); | ======================= | | bug.c:2: error: invalid application of `sizeof' to incomplete type ` | Internal compiler error: Error reporting routines re-entered. | Please submit a full bug report, [etc.] | | The culprit is the code in c-objc-common.c (c_tree_printer) <case 'T'>: | | case 'T': | if (TREE_CODE (t) == TYPE_DECL) | { | if (DECL_NAME (t)) | n = (*lang_hooks.decl_printable_name) (t, 2); | } | else | { | t = TYPE_NAME (t); | if (t) | n = IDENTIFIER_POINTER (t); | } | break; | | In the above case t is a RECORD_TYPE, but TYPE_NAME (t) is a TYPE_DECL. | So there's some logic missing to handle this case. In general, there is a "type" problem in both C and C++ front ends. The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as opposed to an IDENTIFIER_NODE. However, at various occasions I found that a TYPE_NAME would return an IDENTIFIER_NODE. That is a clear bug in both front ends ans should be hunt. Obviously, you have identified a place where instead of correcting the problem the pretty-printer had assumed that TYPE_NAME will always return an IDENTIFIER_NODE -- despite the documentation. I believe a proper PR should be filled so that both front ends are cured from that confusion. -- Gaby
Subject: Re: [3.4 regression] ICE for sizofe of incomplete type On 7 Dec, gdr at integrable-solutions dot net wrote: > In general, there is a "type" problem in both C and C++ front ends. > The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as > opposed to an IDENTIFIER_NODE. However, at various occasions I found > that a TYPE_NAME would return an IDENTIFIER_NODE. That is a clear bug > in both front ends ans should be hunt. Obviously, you have identified a > place where instead of correcting the problem the pretty-printer had > assumed that TYPE_NAME will always return an IDENTIFIER_NODE -- > despite the documentation. I believe a proper PR should be filled so > that both front ends are cured from that confusion. > > -- Gaby Would you mind filing this PR then? Thanks, Volker
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no announcement has been made but it is up on the ftp server already).