| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We never aka vector types because our attributed syntax for it is less
comprehensible than the typedefs. This leaves the user in the dark when
the typedef isn't named that well.
Example:
v2s v; v4f w;
w = v;
The naming in this cases isn't even that bad, but the error we give is
useless without looking up the actual typedefs.
t.c:6:5: error: assigning to 'v4f' from incompatible type 'v2s'
Now:
t.c:6:5: error: assigning to 'v4f' (vector of 4 'float' values) from
incompatible type 'v2s' (vector of 2 'int' values)
We do this for all diagnostics that print a vector type.
llvm-svn: 207267
|
| |
|
|
|
|
|
|
| |
of descending into the subelements.
rdar://problem/8345836
llvm-svn: 117749
|
| |
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
| |
|
|
|
|
| |
before declaration is finalized.
llvm-svn: 90600
|
| |
|
|
| |
llvm-svn: 85079
|
| |
|
|
| |
llvm-svn: 84889
|
| |
|
|
| |
llvm-svn: 84888
|
| |
|
|
|
|
| |
This ensures that arrays of float3 are correctly padded.
llvm-svn: 84833
|
| |
|
|
|
|
|
|
|
| |
don't support. While it would be nice to support this eventually,
this form is not common at all (just seen in gcc testsuite) and
it might be better to model vector_size as a type attribute anyway.
For now just emit a nice error on it.
llvm-svn: 71633
|
| |
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
| |
|
|
|
|
| |
C*. They're required errors in C++.
llvm-svn: 64964
|
| |
|
|
|
|
|
| |
error, since both C99 and C++ consider it an error. For reference, GCC
makes this a warning while G++ makes it an error.
llvm-svn: 63435
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
llvm-svn: 63242
|
| |
|
|
| |
llvm-svn: 49942
|
|
|
llvm-svn: 46343
|
