summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema/vector-cast.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "PR17164: Change clang's default behavior from ↵Mitch Phillips2020-01-231-15/+8
| | | | | | | | | | | | -flax-vector-conversions=all to -flax-vector-conversions=integer." This patch broke the Sanitizer buildbots. Please see the commit's differential revision for more information (https://reviews.llvm.org/D67678). This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486. (cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
* PR17164: Change clang's default behavior from -flax-vector-conversions=all ↵Richard Smith2020-01-171-8/+15
| | | | | | | | | | | | | | | | | | to -flax-vector-conversions=integer. Summary: See proposal on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html Reviewers: SjoerdMeijer, eli.friedman Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67678 (cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
* [Sema] Fix lax conversion between non ext vectorsBruno Cardoso Lopes2017-08-011-0/+8
| | | | | | | | | | r282968 introduced a regression due to the lack of proper testing. Re-add lax conversion support between non ext vectors for compound assignments and add a test for that. rdar://problem/28639467 llvm-svn: 309722
* [Sema] Support implicit scalar to vector conversionsSimon Dardis2017-05-121-3/+2
| | | | | | | | | | | | | | | | | | This patch teaches clang to perform implicit scalar to vector conversions when one of the operands of a binary vector expression is a scalar which can be converted to the element type of the vector without truncation following GCC's implementation. If the (constant) scalar is can be casted safely, it is implicitly casted to the vector elements type and splatted to produce a vector of the same type. Contributions from: Petar Jovanovic Reviewers: bruno, vkalintiris Differential Revision: https://reviews.llvm.org/D25866 llvm-svn: 302935
* [Sema] Support lax conversions for compound assignmentsBruno Cardoso Lopes2016-09-301-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support lax convertions on compound assignment expressions like: typedef __attribute__((vector_size(8))) double float64x1_t; typedef __attribute__((vector_size(16))) double float64x2_t; float64x1_t vget_low_f64(float64x2_t __p0); double c = 3.0; float64x2_t v = {0.0, 1.0}; c += vget_low_f64(v); This restores one more valid behavior pre r266366, and is a incremental follow up from work committed in r274646. While here, make the check more strict, add FIXMEs, clean up variable names to match what they can actually be and update testcases to reflect that. We now reject: typedef float float2 __attribute__ ((vector_size (8))); double d; f2 += d; which doesn't fit as a direct bitcast anyway. Differential Revision: https://reviews.llvm.org/D24472 rdar://problem/28033929 llvm-svn: 282968
* [SemaExpr] Support assignments from vector to scalars with same sizeBruno Cardoso Lopes2016-07-061-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before r266366, clang used to support constructs like: typedef __attribute__((vector_size(8))) double float64x1_t; typedef __attribute__((vector_size(16))) double float64x2_t; float64x1_t vget_low_f64(float64x2_t __p0); double y = 3.0 + vget_low_f64(v); But it would reject: double y = vget_low_f64(v) + 3.0; It also always rejected assignments: double y = vget_low_f64(v); This patch: (a) revivies the behavior of `3.0 + vget_low_f64(v)` prior to r266366, (b) add support for `vget_low_f64(v) + 3.0` and (c) add support for assignments. These vector semantics have never really been tied up but it seems odd that we used to support some binop froms but do not support assignment. If we did support scalar for the purposes of arithmetic, we should probably be able to reinterpret as scalar for the purposes of assignment too. Differential Revision: http://reviews.llvm.org/D21700 rdar://problem/26093791 llvm-svn: 274646
* In vector comparisons, handle scalar LHS just as we handle scalar RHSReid Kleckner2016-04-141-1/+6
| | | | | | | | | | | | Summary: Fixes PR27258 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D19123 llvm-svn: 266366
* Fix the equal-vector-size rule for reinterpret_casts in C++John McCall2015-07-231-0/+8
| | | | | | | | | | | | | to consider the storage size of the vector instead of its sizeof. In other words, ban <3 x int> to <4 x int> casts, which produced invalid IR anyway. Also, attempt to be a little more rigorous, or at least explicit, about when enums are allowed in these casts. rdar://21901132 llvm-svn: 243069
* Make test pass on 32 bit architectures.Benjamin Kramer2014-04-251-1/+1
| | | | llvm-svn: 207268
* Print detailed vector type information on diagnostics.Benjamin Kramer2014-04-251-8/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* Tighten lax vector-conversion rules and enforce them consistently.John McCall2014-02-041-0/+10
| | | | | | | | | | | | | | | | | | | | 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
* In areVectorOperandsLaxBitCastable() allow bitcast between a vector and scalar.Argyrios Kyrtzidis2014-01-091-0/+8
| | | | | | rdar://15779837. llvm-svn: 198856
* Fix directive parsing in VerifyDiagnosticConsumer so that it ensures that ↵Andy Gibbs2012-10-191-6/+6
| | | | | | | | "expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" directive. A very few test-cases had to be amended to adhere to the new rule. Patch reviewed by David Blaikie. llvm-svn: 166279
* Unpluralize -Wfoo-conversions warnings for consistency.David Blaikie2012-03-151-1/+1
| | | | | | | | | | | | Err on the side of brevity and rename (while providing aliases for the original name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for consistency with constant, literal, string, and sign conversion warnings. And name the diagnostic groups explicitly while I'm here rather than rewriting the string in the groups and sema td files. Curiously, vector-conversion is not under -Wconversion. Perhaps it should be. llvm-svn: 152776
* Whenever we complain about a failed initialization of a function orDouglas Gregor2010-04-221-1/+1
| | | | | | | | | | | | | | | | | method parameter, provide a note pointing at the parameter itself so the user does not have to manually look for the function/method being called and match up parameters to arguments. For example, we now get: t.c:4:5: warning: incompatible pointer types passing 'long *' to parameter of type 'int *' [-pedantic] f(long_ptr); ^~~~~~~~ t.c:1:13: note: passing argument to parameter 'x' here void f(int *x); ^ llvm-svn: 102038
* Improve diagnostics when we fail to convert from a source type to aDouglas Gregor2010-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - 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
* Don't perform integer promotions on the operand to a cast; this Eli Friedman2009-08-151-1/+1
| | | | | | | simplifies the AST, and can matter in some rare cases involving casts to vector types. Patch by Enea Zaffanella. llvm-svn: 79126
* OpenCL 1.0 support: explicit casts to ext-vector typesNate Begeman2009-06-261-2/+2
| | | | llvm-svn: 74247
* adjust for the new -Wvector-conversions optionChris Lattner2009-04-171-1/+9
| | | | llvm-svn: 69366
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Report errors for invalid casts from/to vectors.Anders Carlsson2007-11-271-0/+30
llvm-svn: 44350
OpenPOWER on IntegriCloud