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
getTypeSize (which rounds up sizes) in order to issue diagnostics
when casting to mismatched vector sizes; instead of crashing in IRGen.
// rdar:// 16196902. Reviewed offline by John McCall.
llvm-svn: 203175
When a lax conversion featured a vector and a non-vector, we were
only requiring the non-vector to be a scalar type, but really it
needs to be a real type (i.e. integral or real floating); it is
not reasonable to allow a pointer, member pointer, or complex
type here.
r198474 required lax conversions to match in "data size", i.e.
element size * element count, forbidding matches that happen
only because a vector is rounded up to the nearest power of two
in size. Unfortunately, the erroneous logic was repeated in
several different places; unify them to use the new condition,
so that it triggers for arbitrary conversions and not just
those performed as part of binary operator checking.
rdar://15931426
llvm-svn: 200810
consideration the num-of-elements*width-of-element width.
Disallow casts when such width is not equal between the vector types otherwise
we may end up with an invalid LLVM bitcast.
rdar://15722308.
llvm-svn: 198474
vectors that are the same size. Fix up testcases accordingly and add a new one
to make sure we still error if lax vector conversions are disabled.
Fixes rdar://8328190
llvm-svn: 112122
__real myvec and __imag myvec, since they aren't all that useful (it's
just an identity function) but we might want to use them in more
restricted cases in the future (e.g., "__real mycomplexvec" could
extract the real parts of a vector of complex numbers).
llvm-svn: 106601
of the callers of isRealType() already assumed this, and one of them
(increment/decrement) mistakenly permitted increments of vector types
because of it.
llvm-svn: 106596
types, updating callers of both isFloatingType() and
isRealFloatingType() accordingly. Caught at least one issue where we
allowed one to declare a vector of vectors (!), along with cleaning up
the standard-conversion logic for C++.
llvm-svn: 106595
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
- 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
Handle rules for ExtVector + ExtVector and ExtVector + Scalar operations.
Fix problem Eli noticed where we were allowing pointer types to be splatted to
vector elements.
llvm-svn: 74404
Benjamin Kramer