First Last Prev Next    No search results available
Details
: [llvmg++] Enum types are incorrectly shrunk to smaller th...
Bug#: 125
: tools
: llvm-g++
Status: RESOLVED
Resolution: FIXED
: All
: All
: 1.0
: P2
: normal
: 1.1

:
: compile-fail
:
:
  Show dependency tree - Show dependency graph
People
Reporter: John T. Criswell <criswell@uiuc.edu>
Assigned To: Chris Lattner <sabre@nondot.org>

Attachments
Source file causing the problem. (5.15 KB, text/plain)
2003-11-18 12:07, John T. Criswell
Details
Reduced test case (1.10 KB, text/plain)
2003-11-18 13:21, John T. Criswell
Details


Note

You need to log in before you can comment on or make changes to this bug.

Related actions


Description:   Opened: 2003-11-18 11:48
Whe compiling xpdf, the following assertion fails:

cc1plus: ../../gcc-3.4/gcc/llvm-expand.c:3393: llvm_expand_constructor_elements:
Assertion `((FieldType)->ID >= BoolTyID && (FieldType)->ID <= LongTyID) && "Bad
bitfield member ty!"' failed.
Gfx.cc:223: internal compiler error: Aborted

The offending file is Gfx.cc.  I will try to reduce it to something more manageable.
------- Comment #1 From Chris Lattner 2003-11-18 11:53:45 -------
Great, thanks.  When you get a nice tasty testcase, please attach it to this
bug. :)
------- Comment #2 From John T. Criswell 2003-11-18 12:07:06 -------
Created an attachment (id=25) [details]
Source file causing the problem.

Source code that triggers the bug.
Unfortunetly, it relies upon too many header files from xpdf.
Still working on reducing it.
------- Comment #3 From John T. Criswell 2003-11-18 13:21:28 -------
Created an attachment (id=26) [details]
Reduced test case

This is a reduced test cause which triggers the assertion.
It is a single source file and requires no headers from xpdf.
------- Comment #4 From Chris Lattner 2003-11-18 14:13:48 -------
Here's a further reduced testcase:

enum TchkType {
  tchkNum, tchkString, tchkSCN, tchkNone
};

struct Operator {
  TchkType tchk[8];
};

Operator opTab[] = {
  {{tchkNum, tchkNum, tchkString} }
};

------- Comment #5 From Chris Lattner 2003-11-18 14:56:49 -------
Fixed.  This was due to me misunderstanding the difference between
TYPE_PRECISION and TYPE_SIZE.

Testcase here:  Regression/C++Frontend/2003-11-18-EnumArray.cpp

Patch is:
$ diff llvm-types.c~ llvm-types.c -u
--- llvm-types.c~       2003-11-09 10:37:09.000000000 -0600
+++ llvm-types.c        2003-11-18 14:53:23.000000000 -0600
@@ -1240,22 +1240,11 @@
   case VOID_TYPE:        return VoidTy;
   case BOOLEAN_TYPE:     return BoolTy;
 
-  case ENUMERAL_TYPE:    /* Treat the same as integral type, but round up */
-  case INTEGER_TYPE: {
-    unsigned Size = TYPE_PRECISION(type);
-    if (Size == 0)
-      Size = TREE_INT_CST_LOW(TYPE_SIZE(type));
+  case ENUMERAL_TYPE:
+  case INTEGER_TYPE:
+    return llvm_type_get_integer(TREE_INT_CST_LOW(TYPE_SIZE(type)),
+                                 TREE_UNSIGNED(type));
 
-    if (TREE_CODE(type) == ENUMERAL_TYPE) {
-      /* Round enumeration size to a specified type */
-      if (Size > 0 && Size < 8) Size = 8;
-      if (Size > 8 && Size < 16) Size = 16;
-      if (Size > 16 && Size < 32) Size = 32;
-      if (Size > 32 && Size < 64) Size = 64;
-    }
-
-    return llvm_type_get_integer(Size, TREE_UNSIGNED(type));
-  }
   case REAL_TYPE:
     switch(TYPE_PRECISION(type)) {
     case 32: return FloatTy;


FWIW, this might also fix a large number of C++ warnings when linking programs,
and I wouldn't be suprised if this wasn't causing some C++ miscompilations as
well...

-Chris

First Last Prev Next    No search results available