Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
cases.
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
|
|
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
|