summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema/ext_vector_casts.c
Commit message (Collapse)AuthorAgeFilesLines
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. llvm-svn: 371817
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-131-1/+1
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. llvm-svn: 371813
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. llvm-svn: 371805
* [Sema] Enable -Wimplicit-float-conversion for integral to floating point ↵Ziang Wan2019-08-011-5/+5
| | | | | | | | | | | | | | | | precision loss Issue an warning when the code tries to do an implicit int -> float conversion, where the float type ha a narrower significant than the float type. The new warning is controlled by flag -Wimplicit-int-float-conversion, under -Wimplicit-float-conversion and -Wconversion. It is also silenced when c++11 narrowing warning is issued. Differential Revision: https://reviews.llvm.org/D64666 llvm-svn: 367497
* Revert "[Sema] Enable -Wimplicit-float-conversion for integral to floating ↵Petr Hosek2019-07-251-4/+4
| | | | | | | | | | | point precision loss" This reverts commit r366972 which broke the following tests: Clang :: CXX/dcl.decl/dcl.init/dcl.init.list/p7-0x.cpp Clang :: CXX/dcl.decl/dcl.init/dcl.init.list/p7-cxx11-nowarn.cpp llvm-svn: 366979
* [Sema] Enable -Wimplicit-float-conversion for integral to floating point ↵Ziang Wan2019-07-251-4/+4
| | | | | | | | | | | | | | | precision loss Issue an warning when the code tries to do an implicit int -> float conversion, where the float type ha a narrower significant than the float type. The new warning is controlled by flag -Wimplicit-int-float-conversion, under -Wimplicit-float-conversion and -Wconversion. Differential Revision: https://reviews.llvm.org/D64666 llvm-svn: 366972
* Reverted D52835 to fix review commentsDavid Bolvansky2018-11-141-1/+1
| | | | llvm-svn: 346866
* [Diagnostics] Check integer to floating point number implicit conversionsDavid Bolvansky2018-11-141-1/+1
| | | | | | | | | | | | | | | | | Summary: GCC already catches these situations so we should handle it too. GCC warns in C++ mode only (does anybody know why?). I think it is useful in C mode too. Reviewers: rsmith, erichkeane, aaron.ballman, efriedma, xbolva00 Reviewed By: xbolva00 Subscribers: efriedma, craig.topper, scanon, cfe-commits Differential Revision: https://reviews.llvm.org/D52835 llvm-svn: 346865
* [Sema] Make extended vectors of `bool` an error.George Burgess IV2016-01-281-0/+2
| | | | | | | | | | | | | | In OpenCL, `bool` vectors are a reserved type, and are therefore illegal. Outside of OpenCL, if we try to make an extended vector of N `bool`s, Clang will lower it to an `[N x i1]`. LLVM has no ABI for bitvectors, so lots of operations on such vectors are thoroughly broken. As a result, this patch makes them illegal in everything else, as well. :) Differential Revision: http://reviews.llvm.org/D15721 llvm-svn: 259011
* [Sema] Be consistent about diagnostic wording: always use "cannot".Davide Italiano2015-08-151-6/+6
| | | | | | Discussed with Richard Smith. llvm-svn: 245162
* Print detailed vector type information on diagnostics.Benjamin Kramer2014-04-251-12/+12
| | | | | | | | | | | | | | | | | | | | | | 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
* Improved semantics for implicit scalar -> extvector conversions.Stephen Canon2014-04-031-4/+37
| | | | llvm-svn: 205521
* C. Compare vector sizes using their raw element size instead ofFariborz Jahanian2014-03-061-0/+10
| | | | | | | | 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
* Tighten lax vector-conversion rules and enforce them consistently.John McCall2014-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Add an additional check in test/Sema/ext_vector_casts.cArgyrios Kyrtzidis2014-01-041-0/+1
| | | | llvm-svn: 198479
* [Sema] When checking if a bitcast is appropriate between vector types, take intoArgyrios Kyrtzidis2014-01-041-0/+4
| | | | | | | | | | | 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
* Make test portable.Ted Kremenek2013-10-101-1/+1
| | | | llvm-svn: 192338
* Fix getIntegerTypeOrder() to properly handle enums by first unwrapping their ↵Ted Kremenek2013-10-101-0/+24
| | | | | | | | | | | | underlying integer type. This is a precondition for calling getIntegerRank(). Fixes an assertion failure in a test case involving vectors. Fixes <rdar://problem/15091442> Please somebody check this. llvm-svn: 192334
* Fix Sema::CheckVectorOperands so that it doesn't try to insert a cast ↵Eli Friedman2011-06-231-1/+1
| | | | | | | | expression into the LHS of a compound assignment. Fixes compound assignment of various "compatible" vector types, including NEON-vector and gcc-vector types. <rdar://problem/9640356> llvm-svn: 133737
* With lax vector conversions (the default) make sure we convert between twoEric Christopher2010-08-261-1/+1
| | | | | | | | | 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
* Clean up the diagnostic complaining about the element type of a vectorDouglas Gregor2010-06-301-1/+1
| | | | | | type so that it actually complains about the element type itself. llvm-svn: 107299
* Vector types are not arithmetic types, either. Note that we now banDouglas Gregor2010-06-221-0/+1
| | | | | | | | | __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
* Teach Type::isRealType() that vector types are never real types. AllDouglas Gregor2010-06-221-0/+4
| | | | | | | | 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
* Type Type::isRealFloatingType() that vectors are not floating-pointDouglas Gregor2010-06-221-0/+2
| | | | | | | | | 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
* 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
* OpenCL 1.0 support: Nate Begeman2009-06-281-0/+22
| | | | | | | | 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
* OpenCL 1.0 support: explicit casts to ext-vector typesNate Begeman2009-06-261-0/+23
llvm-svn: 74247
OpenPOWER on IntegriCloud