When generating records/unions, the same enum type may be generated more
than once (with different names). In these cases, the name of the enum
values are not sufficiently unique to prevent multiple declarations. E.g:
typedef enum T3 { enum0val0 } T3;
typedef T3 T2[3];
typedef enum T4 { enum0val0 } T4;
typedef union T1 { T2 field0; T4 field1; char field2; } T1;
Added a unique suffix to enum values so that multiple identical enum types do
not use the same enum value names.
One example of this bug is produced by:
ABITestGen.py --no-unsigned --no-vector --no-complex --no-bool \
--max-args 0 --max-record-depth 1 -o inputs/test.9921.a.c \
-T inputs/test.9921.b.c -D inputs/test.9921.driver.c \
--min=9921 --count=1
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216166 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
- 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
Chris Bieneman