summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaChecking.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Hexagon] Diagnose intrinsics not supported by selected CPU/HVXKrzysztof Parzyszek2018-07-121-2/+792
| | | | llvm-svn: 336933
* [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %tu/%td on DarwinAlex Lorenz2018-07-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The '%tu'/'%td' as formatting specifiers have been used to print out the NSInteger/NSUInteger values for a long time. Typically their ABI matches, but that's not the case on watchOS. The ABI difference boils down to the following: - Regular 32-bit darwin targets (like armv7) use 'ptrdiff_t' of type 'int', which matches 'NSInteger'. - WatchOS arm target (armv7k) uses 'ptrdiff_t' of type 'long', which doesn't match 'NSInteger' of type 'int'. Because of this ABI difference these specifiers trigger -Wformat warnings only for watchOS builds, which is really inconvenient for cross-platform code. This patch avoids this -Wformat warning for '%tu'/'%td' and NS[U]Integer only, and instead uses the new -Wformat-pedantic warning that JF introduced in https://reviews.llvm.org/D47290. This is acceptable because Darwin guarantees that, despite the watchOS ABI differences, sizeof(ptrdiff_t) == sizeof(NS[U]Integer), and alignof(ptrdiff_t) == alignof(NS[U]Integer) so the warning is therefore noisy for pedantic reasons. I'll update public documentation to ensure that this behaviour is properly communicated. rdar://41739204 Differential Revision: https://reviews.llvm.org/D48852 llvm-svn: 336396
* [Sema] Consider all format_arg attributes.Michael Kruse2018-07-041-6/+15
| | | | | | | | | | | | | | | | If a function has multiple format_arg attributes, clang only considers the first it finds (because AttributeLists are in reverse order, not necessarily the textually first) and ignores all others. Loop over all FormatArgAttr to print warnings for all declared format_arg attributes. For instance, libintl's ngettext (select plural or singular version of format string) has two __format_arg__ attributes. Differential Revision: https://reviews.llvm.org/D48734 llvm-svn: 336239
* [X86] Remove masking from the avx512 rotate builtins. Use a select builtin ↵Craig Topper2018-06-301-12/+12
| | | | | | instead. llvm-svn: 336036
* [X86] Remove masking from the avx512 packed sqrt builtins. Use select ↵Craig Topper2018-06-291-2/+2
| | | | | | builtins instead. llvm-svn: 335945
* [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on DarwinJF Bastien2018-06-221-30/+36
| | | | | | | | | | | | | | | | | | | | | | | Summary: Pick D42933 back up, and make NSInteger/NSUInteger with %zu/%zi specifiers on Darwin warn only in pedantic mode. The default -Wformat recently started warning for the following code because of the added support for analysis for the '%zi' specifier. NSInteger i = NSIntegerMax; NSLog(@"max NSInteger = %zi", i); The problem is that on armv7 %zi is 'long', and NSInteger is typedefed to 'int' in Foundation. We should avoid this warning as it's inconvenient to our users: it's target specific (happens only on armv7 and not arm64), and breaks their existing code. We should also silence the warning for the '%zu' specifier to ensure consistency. This is acceptable because Darwin guarantees that, despite the unfortunate choice of typedef, sizeof(size_t) == sizeof(NS[U]Integer), the warning is therefore noisy for pedantic reasons. Once this is in I'll update public documentation. Related discussion on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058050.html <rdar://36874921&40501559> Reviewers: ahatanak, vsapsai, alexshap, aaron.ballman, javed.absar, jfb, rjmccall Subscribers: kristof.beyls, aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D47290 llvm-svn: 335393
* [x86] Teach the builtin argument range check to allow invalid ranges inChandler Carruth2018-06-211-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dead code. This is important for C++ templates that essentially compute the valid input in a way that is constant and will cause all the invalid cases to be dead code that is deleted. Code in the wild actually does this and GCC also accepts these kinds of patterns so it is important to support it. To make this work, we provide a non-error path to diagnose these issues, and use a default-error warning instead. This keeps the relatively strict handling but prevents nastiness like SFINAE on these errors. It also allows us to safely use the system to diagnose this only when it occurs at runtime (in emitted code). Entertainingly, this required fixing the syntax in various other ways for the x86 test because we never bothered to diagnose that the returns were invalid. Since debugging these compile failures was super confusing, I've also improved the diagnostic to actually say what the value was. Most of the checks I've made ignore this to simplify maintenance, but I've checked it in a few places to make sure the diagnsotic is working. Depends on D48462. Without that, we might actually crash some part of the compiler after bypassing the error here. Thanks to Richard, Ben Kramer, and especially Craig Topper for all the help here. Differential Revision: https://reviews.llvm.org/D48464 llvm-svn: 335309
* [X86] Remove masking from the 512-bit floating point max/min builtins. Use ↵Craig Topper2018-06-211-4/+6
| | | | | | select in IR instead. llvm-svn: 335200
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-4/+11
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335050
* Reverting due to line ending changes; will reapply after addressing that.Aaron Ballman2018-06-191-816/+809
| | | | llvm-svn: 335049
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-809/+816
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335048
* [X86] __builtin_ia32_prord512_mask, __builtin_ia32_prorq512_mask, ↵Craig Topper2018-06-151-0/+2
| | | | | | | | __builtin_ia32_shufpd should only accept an ICE constant. The rotates also need to check for the immediate to fit in 8-bits. Shufpd already checks its immediate range. llvm-svn: 334847
* [X86] The immediate argument to getmantpd*_mask should be an ICE and it ↵Craig Topper2018-06-151-0/+6
| | | | | | | | should only be 4 bits wide. We already checked this for the scalar version, but missed the vector version somehow. llvm-svn: 334846
* [X86] Rename __builtin_ia32_pslldqi128 to ↵Craig Topper2018-06-141-8/+6
| | | | | | | | | | | | __builtin_ia32_pslldqi128_byteshift and similar for other sizes. Remove the multiply by 8 from the header files. The previous names took the shift amount in bits to match gcc and required a multiply by 8 in the header. This creates a misleading error message when we check the range of the immediate to the builtin since the allowed range also got multiplied by 8. This commit changes the builtins to use a byte shift amount to match the underlying instruction and the Intel intrinsic. Fixes the remaining issue from PR37795. llvm-svn: 334773
* Correct behavior of __builtin_*_overflow and constexpr.Erich Keane2018-06-131-9/+21
| | | | | | | | | | Enable these builtins to be called across a lambda boundary with captureless const/constexpr, as brought up by Eli here: https://reviews.llvm.org/D48040 Differential Revision: https://reviews.llvm.org/D48053 llvm-svn: 334597
* [X86] Remove masking from avx512vbmi2 concat and shift by immediate ↵Craig Topper2018-06-131-18/+18
| | | | | | builtins. Use select builtins instead. llvm-svn: 334577
* [AArch64] Corrected FP16 Intrinsic range checks in Clang + added Sema testsLuke Geeson2018-06-121-4/+4
| | | | | | | | | | | | | | | | | | Summary: This fixes the ranges for the vcvth family of FP16 intrinsics in the clang front end. Previously it was accepting incorrect ranges -Changed builtin range checking in SemaChecking -added tests SemaCheck changes - included in their own file since no similar one exists -modified existing tests to reflect new ranges Reviewers: SjoerdMeijer, javed.absar Reviewed By: SjoerdMeijer Subscribers: kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D47592 llvm-svn: 334489
* [X86] Properly account for the immediate being multiplied by 8 in the ↵Craig Topper2018-06-111-1/+1
| | | | | | | | immediate range checking for BI__builtin_ia32_psrldqi128 and friends. The limit was set to 1023 which only up to 127*8. It needs to be 2047 to allow 255*8. llvm-svn: 334416
* [X86] Remove masking from dbpsadbw builtins, use select builtin instead.Craig Topper2018-06-111-3/+3
| | | | llvm-svn: 334385
* [X86] Remove masking from the 512-bit packed floating point add/sub/mul/div ↵Craig Topper2018-06-101-8/+8
| | | | | | builtins. Use select in IR instead. llvm-svn: 334359
* [X86] Fold masking into subvector extract builtins.Craig Topper2018-06-081-12/+12
| | | | | | | | I'm looking into making the select builtins require avx512f, avx512bw, or avx512vl since masking operations generally require those features. The extract builtins are funny because the 512-bit versions return a 128 or 256 bit vector with masking even when avx512vl is not supported. llvm-svn: 334330
* [X86] Add builtins for vpermq/vpermpd instructions to enable target feature ↵Craig Topper2018-06-081-0/+4
| | | | | | checking. llvm-svn: 334311
* [X86] Change immediate type for some builtins from char to int.Craig Topper2018-06-081-0/+4
| | | | | | These builtins are all handled by CGBuiltin.cpp so it doesn't much matter what the immediate type is, but int matches the intrinsic spec. llvm-svn: 334310
* [X86] Add builtins for shufps and shufpd to enable target feature and ↵Craig Topper2018-06-081-0/+6
| | | | | | immediate range checking. llvm-svn: 334266
* [X86] Add builtins for pshufd, pshuflw, and pshufhw to enable target feature ↵Craig Topper2018-06-081-0/+9
| | | | | | and immediate range checking. llvm-svn: 334265
* [X86] Add subvector insert and extract builtins to enable target feature ↵Craig Topper2018-06-081-0/+32
| | | | | | | | checking and immediate range checking. Test changes are due to differences in how we generate undef elements now. We also changed the types used for extractf128_si256/insertf128_si256 to match the signature of the builtin that previously existed which this patch resurrects. This also matches gcc. llvm-svn: 334261
* [X86] Add builtins for vpermilps/pd instructions to enable target feature ↵Craig Topper2018-06-081-0/+6
| | | | | | checking. llvm-svn: 334256
* [X86] Add builtins for blend with immediate control to enforce target ↵Craig Topper2018-06-081-0/+8
| | | | | | feature requirements and check immediate range. llvm-svn: 334249
* [X86] Add builtins for shuff32x4/shuff64x2/shufi32x4/shuff64x2 to enable ↵Craig Topper2018-06-071-0/+8
| | | | | | target feature checking and immediate range checking. llvm-svn: 334244
* [MS] Re-add support for the ARM interlocked bittest intrinscsReid Kleckner2018-06-071-0/+41
| | | | | | | | | | | | | | | Adds support for these intrinsics, which are ARM and ARM64 only: _interlockedbittestandreset_acq _interlockedbittestandreset_rel _interlockedbittestandreset_nf _interlockedbittestandset_acq _interlockedbittestandset_rel _interlockedbittestandset_nf Refactor the bittest intrinsic handling to decompose each intrinsic into its action, its width, and its atomicity. llvm-svn: 334239
* [X86] Add builtins for VALIGNQ/VALIGND to enable proper target feature checking.Craig Topper2018-06-071-0/+6
| | | | | | | | We still emit shufflevector instructions we just do it from CGBuiltin.cpp now. This ensures the intrinsics that use this are only available on CPUs that support the feature. I also added range checking to the immediate, but only checked it is 8 bits or smaller. We should maybe be stricter since we never use all 8 bits, but gcc doesn't seem to do that. llvm-svn: 334237
* [X86] Add back builtins for _mm_slli_si128/_mm_srli_si128 and similar ↵Craig Topper2018-06-071-0/+8
| | | | | | | | | | intrinsics. We still lower them to native shuffle IR, but we do it in CGBuiltin.cpp now. This allows us to check the target feature and ensure the immediate fits in 8 bits. This also improves our -O0 codegen slightly because we're able to see the zeroinitializer in the shuffle. It looks like it got lost behind a store+load previously. llvm-svn: 334208
* [X86] Add back _mask, _maskz, and _mask3 builtins for some 512-bit ↵Craig Topper2018-06-071-4/+16
| | | | | | | | | | | | | | | | | | | | | | | fmadd/fmsub/fmaddsub/fmsubadd builtins. Summary: We recently switch to using a selects in the intrinsics header files for FMA instructions. But the 512-bit versions support flavors with rounding mode which must be an Integer Constant Expression. This has forced those intrinsics to be implemented as macros. As it stands now the mask and mask3 intrinsics evaluate one of their macro arguments twice. If that argument itself is another intrinsic macro, we can end up over expanding macros. Or if its something we can CSE later it would show up multiple times when it shouldn't. I tried adding __extension__ around the macro and making it an expression statement and declaring a local variable. But whatever name you choose for the local variable can never be used as the name of an input to the macro in user code. If that happens you would end up with the same name on the LHS and RHS of an assignment after expansion. We might be safe if we use __ in front of the variable names because those names are reserved and user code shouldn't use that, but I wasn't sure I wanted to make that claim. The other option which I've chosen here, is to add back _mask, _maskz, and _mask3 flavors of the builtin which we will expand in CGBuiltin.cpp to replicate the argument as needed and insert any fneg needed on the third operand to make a subtract. The _maskz isn't truly necessary if we have an unmasked version or if we use the masked version with a -1 mask and wrap a select around it. But I've chosen to make things more uniform. I separated out the scalar builtin handling to avoid too many things going on in EmitX86FMAExpr. It was different enough due to the extract and insert that the minor duplication of the CreateCall was probably worth it. Reviewers: tkrupa, RKSimon, spatel, GBuella Reviewed By: tkrupa Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47724 llvm-svn: 334159
* [X86] Add builtins for vector element insert and extract for different 128 ↵Craig Topper2018-06-061-3/+24
| | | | | | | | | | | | | | and 256 bit vector types. Use them to implement the extract and insert intrinsics. Previously we were just using extended vector operations in the header file. This unfortunately allowed non-constant indices to be used with the intrinsics. This is incompatible with gcc, icc, and MSVC. It also introduces a different performance characteristic because non-constant index gets lowered to a vector store and an element sized load. By adding the builtins we can check for the index to be a constant and ensure its in range of the vector element count. User code still has the option to use extended vector operations themselves if they need non-constant indexing. llvm-svn: 334057
* [X86] Make __builtin_ia32_vec_ext_v2si require ICE for its index argument. ↵Craig Topper2018-06-051-0/+7
| | | | | | | | Add warnings for out of range indices for __builtin_ia32_vec_ext_v2si, __builtin_ia32_vec_ext_v4hi, and __builtin_ia32_vec_set_v4hi. These should take a constant value for an index and that constant should be a valid element number. llvm-svn: 334051
* [X86] Lowering FMA intrinsics to native IR (Clang part)Gabor Buella2018-05-301-22/+4
| | | | | | | | | | | | | | | | This patch replaces all packed (and scalar without rounding mode) fused intrinsics with fmadd/fmaddsub variations. Then fmadd/fmaddsub are lowered to native IR. Patch by tkrupa Reviewers: craig.topper, sroland, spatel, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47444 llvm-svn: 333555
* Follow-up fix for nonnull atomic non-member functionsJF Bastien2018-05-251-2/+2
| | | | | | | | Handling of the third parameter was only checking for *_n and not for the C11 variant, which means that cmpxchg of a 'desired' 0 value was erroneously warning. Handle C11 properly, and add extgensive tests for this as well as NULL pointers in a bunch of places. Fixes r333246 from D47229. llvm-svn: 333290
* Make atomic non-member functions as nonnullJF Bastien2018-05-251-15/+31
| | | | | | | | | | | | | | | | | Summary: As a companion to libc++ patch https://reviews.llvm.org/D47225, mark builtin atomic non-member functions which accept pointers as nonnull. The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). <rdar://problem/18473124> Reviewers: arphaman Subscribers: aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D47229 llvm-svn: 333246
* [X86] Remove mask argument from some builtins that are handled completely in ↵Craig Topper2018-05-221-1/+1
| | | | | | CGBuiltin.cpp. Just wrap a select builtin around them in the header file instead. llvm-svn: 333027
* [X86] Remove some unused builtins.Craig Topper2018-05-211-8/+0
| | | | | | These were upgraded to native shufflevectors months ago. llvm-svn: 332829
* Address post-commit review comments after r328731. NFC.Akira Hatanaka2018-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | - Define a function (canPassInRegisters) that determines whether a record can be passed in registers based on language rules and target-specific ABI rules. - Set flag RecordDecl::ParamDestroyedInCallee to true in MSVC mode and remove ASTContext::isParamDestroyedInCallee, which is no longer needed. - Use the same type (unsigned) for RecordDecl's bit-field members. For more background, see the following discussions that took place on cfe-commits. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180326/223498.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/223688.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180409/224754.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226494.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180507/227647.html llvm-svn: 332397
* Enable control flow pruning of float overflow warnings.Richard Trieu2018-05-141-1/+2
| | | | | | | | | Like other conversion warnings, allow float overflow warnings to be disabled in known dead paths of template instantiation. This often occurs when a template template type is a numeric type and the template will check the range of the numeric type before performing the conversion. llvm-svn: 332310
* Added atomic_fetch_min, max, umin, umax intrinsics to clang.Elena Demikhovsky2018-05-131-2/+18
| | | | | | | | | These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering. Updated the clang-extensions document. Differential Revision: https://reviews.llvm.org/D46386 llvm-svn: 332193
* [Hexagon] Implement checking arguments of builtin callsKrzysztof Parzyszek2018-05-111-0/+223
| | | | llvm-svn: 332105
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-34/+34
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Fix float->int conversion warnings when near barriers.Erich Keane2018-05-081-20/+12
| | | | | | | | | | | | As Eli brought up here: https://reviews.llvm.org/D46535 I'd previously messed up this fix by missing conversions that are just slightly outside the range. This patch fixes this by no longer ignoring the return value of convertToInteger. Additionally, one of the error messages wasn't very sensical (mentioning out of range value, when it really was not), so it was cleaned up as well. llvm-svn: 331812
* Correct warning on Float->Integer conversions.Erich Keane2018-05-071-0/+17
| | | | | | | | | | | | | | | | | | As identified and briefly discussed here: https://bugs.llvm.org/show_bug.cgi?id=37305 Converting a floating point number to an integer type when the integral part is out of the range of the integer type is undefined behavior in C. Additionally, CodeGen emits an undef in this situation. HOWEVER, we've been giving a warning that says that the value is changed. This patch corrects the warning to list that it is actually undefined behavior. Differential Revision: https://reviews.llvm.org/D46535 llvm-svn: 331673
* Disallow pointers to const in __sync_fetch_and_xxx.Aaron Ballman2018-05-051-0/+6
| | | | | | | | | | | | Diagnoses code like: void f(const int *ptr) { __sync_fetch_and_add(ptr, 1); } which matches the behavior of GCC and ICC. llvm-svn: 331598
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-1/+1
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-301-1/+1
| | | | | | | | | | | | | | | | | | When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
OpenPOWER on IntegriCloud