Noticed by Roman Divacky.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190311 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114867 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114866 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114865 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114864 91177308-0d34-0410-b5e6-96231b3b80d8

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.

In this commit:
  - Enum types with a promotion type of "int" or "unsigned int" are
  promotable.
  - Tweaked the computation of promotable types for enums
  - For all of the ABIs, treat enum types the same way as their
  underlying types (*not* their promotion types) for argument passing
  and return values
  - Extend the ABI tester with support for enumeration types



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95117 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95095 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79201 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79200 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77022 91177308-0d34-0410-b5e6-96231b3b80d8

More work on the constant struct builder. We now try to layout all constant structs but throw away the result.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77021 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75271 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72405 91177308-0d34-0410-b5e6-96231b3b80d8

printf operands to long to suppress warnings.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72404 91177308-0d34-0410-b5e6-96231b3b80d8

test index.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71295 91177308-0d34-0410-b5e6-96231b3b80d8

Makefile.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71274 91177308-0d34-0410-b5e6-96231b3b80d8

non-padding fields.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71273 91177308-0d34-0410-b5e6-96231b3b80d8

Also, tweak default list of bit-fields to try.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71246 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71201 91177308-0d34-0410-b5e6-96231b3b80d8

 - Support generating structures with bit-fields.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71192 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65810 91177308-0d34-0410-b5e6-96231b3b80d8

of sizes. Turns out we don't care very much about vector types that
don't map to the hardware.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65263 91177308-0d34-0410-b5e6-96231b3b80d8

catching internal consistency problems (esp. w/ reference compiler).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64847 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64846 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63330 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63296 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63286 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63279 91177308-0d34-0410-b5e6-96231b3b80d8

size/alignment/offsetof based tests of types instead of calling
convention tests.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63167 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63024 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62916 91177308-0d34-0410-b5e6-96231b3b80d8

 - Mostly written as an entertaining exercise in enumerating large or
   (countably, naturally) infinite sets. But hey, its useful too!

 - Idea is to number all C-types so that the N-th type can quickly be
   computed, with a good deal of flexibility about what types to
   include, and taking some care so that the (N+1)-th type is
   interestingly different from the N-th type. For example, using the
   default generator, the 1,000,000-th function type is:
--
typedef _Complex int T0;
typedef char T1 __attribute__ ((vector_size (4)));
typedef int T2 __attribute__ ((vector_size (4)));
T2 fn1000000(T0 arg0, signed long long arg1, T1 arg2, T0 arg3);
--
   and the 1,000,001-th type is:
--
typedef _Complex char T0;
typedef _Complex char T2;
typedef struct T1 { T2 field0; T2 field1; T2 field2; } T1;
typedef struct T3 {  } T3;
unsigned short fn1000001(T0 arg0, T1 arg1, T3 arg2);
--

   Computing the 10^1600-th type takes a little less than 1s. :)


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62253 91177308-0d34-0410-b5e6-96231b3b80d8