[Bug c/25301] New: [3.4 regression] ICE for sizofe of incomplete type

[reichelt at gcc dot gnu dot org]

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.


-- 
   Summary: [3.4 regression] ICE for sizofe of incomplete type
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301

Re: [Bug c/25301] New: [3.4 regression] ICE for sizofe of incomplete type

[Gabriel Dos Reis]

reichelt at gcc dot gnu dot org [EMAIL PROTECTED] 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