summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaChecking.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Make __builtin_ia32_readeflags_u32 and __builtin_ia32_writeeflags_u32 ↵Craig Topper2018-04-261-0/+17
| | | | | | | | | | | | only available on 32-bit targets. These builtins can't be handled by the backend on 64-bit targets. So error up front instead of throwing an isel error. Fixes PR37225 Differential Revision: https://reviews.llvm.org/D46132 llvm-svn: 330987
* Improve -Warray-bounds to handle multiple array extents rather than only ↵Aaron Ballman2018-04-241-1/+6
| | | | | | | | handling the top-most array extent. Patch by Bevin Hansson. llvm-svn: 330759
* [Sema] Warn about memcpy'ing non-trivial C structs.Akira Hatanaka2018-04-171-1/+110
| | | | | | | | | | | Issue a warning when non-trivial C structs are copied or initialized by calls to memset, bzero, memcpy, or memmove. rdar://problem/36124208 Differential Revision: https://reviews.llvm.org/D45310 llvm-svn: 330202
* Introduce a new builtin, __builtin_dump_struct, that is useful for dumping ↵Aaron Ballman2018-04-101-0/+57
| | | | | | | | structure contents at runtime in circumstances where debuggers may not be easily available (such as in kernel work). Patch by Paul Semel. llvm-svn: 329762
* Revert r329684 (and follow-ups 329693, 329714). See discussion on ↵Nico Weber2018-04-101-23/+2
| | | | | | https://reviews.llvm.org/D43578. llvm-svn: 329739
* -ftime-report switch support in Clang.Andrew V. Tischenko2018-04-101-2/+23
| | | | | | | | | | The current support of the feature produces only 2 lines in report: -Some general Code Generation Time; -Total time of Backend Consumer actions. This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc. Differential Revision: https://reviews.llvm.org/D43578 llvm-svn: 329684
* Fix typos in clangAlexander Kornienko2018-04-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Fix some handling of AST nodes with diagnostics.Richard Trieu2018-03-281-5/+5
| | | | | | | | | The diagnostic system for Clang can already handle many AST nodes. Instead of converting them to strings first, just hand the AST node directly to the diagnostic system and let it handle the output. Minor changes in some diagnostic output. llvm-svn: 328688
* [Sema] Emit -Winteger-overflow for arguments in function calls, ObjC messages.Volodymyr Sapsai2018-03-271-7/+11
| | | | | | | | | | | | | | rdar://problem/35539384 Reviewers: ahatanak, nicholas, rsmith, jkorous-apple Reviewed By: jkorous-apple Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42938 llvm-svn: 328671
* Drop spurious break; NFCSven van Haastregt2018-03-271-1/+0
| | | | llvm-svn: 328626
* [Builtins] Overload __builtin_operator_new/delete to allow forwarding to ↵Eric Fiselier2018-03-211-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | usual allocation/deallocation functions. Summary: Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins. See llvm.org/PR22634 for more information about the libc++ bug. This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued. One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled. In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`. Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43047 llvm-svn: 328134
* More warnings when double truncation to float: compound assignment is ↵Andrew V. Tischenko2018-03-151-2/+31
| | | | | | supported now. llvm-svn: 327618
* Reland "[Attr] Fix parameter indexing for several attributes"Joel E. Denny2018-03-131-21/+16
| | | | | | | | | Relands r326602 (reverted in r326862) with new test and fix for PR36620. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 327405
* Revert r326602, it caused PR36620.Nico Weber2018-03-071-16/+21
| | | | llvm-svn: 326862
* [Attr] Fix parameter indexing for several attributesJoel E. Denny2018-03-021-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch fixes a number of bugs related to parameter indexing in attributes: * Parameter indices in some attributes (argument_with_type_tag, pointer_with_type_tag, nonnull, ownership_takes, ownership_holds, and ownership_returns) are specified in source as one-origin including any C++ implicit this parameter, were stored as zero-origin excluding any this parameter, and were erroneously printing (-ast-print) and confusingly dumping (-ast-dump) as the stored values. * For alloc_size, the C++ implicit this parameter was not subtracted correctly in Sema, leading to assert failures or to silent failures of __builtin_object_size to compute a value. * For argument_with_type_tag, pointer_with_type_tag, and ownership_returns, the C++ implicit this parameter was not added back to parameter indices in some diagnostics. This patch fixes the above bugs and aims to prevent similar bugs in the future by introducing careful mechanisms for handling parameter indices in attributes. ParamIdx stores a parameter index and is designed to hide the stored encoding while providing accessors that require each use (such as printing) to make explicit the encoding that is needed. Attribute declarations declare parameter index arguments as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This patch rewrites all attribute arguments that are processed by checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared as [Variadic]ParamIdxArgument. The only exception is xray_log_args's argument, which is encoded as a count not an index. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 326602
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-4/+4
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [NFC] Extract method to SourceManager for traversing the macro "stack"George Karpenkov2018-02-091-5/+2
| | | | | | | | | | | | The code for going up the macro arg expansion is duplicated in many places (and we need it for the analyzer as well, so I did not want to duplicate it two more times). This patch is an NFC, so the semantics should remain the same. Differential Revision: https://reviews.llvm.org/D42458 llvm-svn: 324780
* [PR36008] Avoid -Wsign-compare warning for enum constants inAlex Lorenz2018-02-071-0/+10
| | | | | | | | | | | | | typeof expressions This commit looks through typeof type at the original expression when diagnosing -Wsign-compare to avoid an unfriendly diagnostic. rdar://36588828 Differential Revision: https://reviews.llvm.org/D42561 llvm-svn: 324514
* Add support for attribute 'trivial_abi'.Akira Hatanaka2018-02-051-17/+12
| | | | | | | | | | | | | | | | | | | | | | | | | The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
* [AArch64] Add ARMv8.2-A FP16 scalar intrinsicsAbderrazek Zaafrani2018-01-191-0/+2
| | | | | | https://reviews.llvm.org/D41792 llvm-svn: 323006
* [X86][Sema] Range check the constant argument for the vpshld/vpshrd builtins ↵Craig Topper2018-01-111-0/+18
| | | | | | to ensure it fits in 8-bits. llvm-svn: 322247
* [X86][Sema] Remove constant range checks on on builtins that take a char.Craig Topper2018-01-111-37/+0
| | | | | | The constant is already reduced to 8-bits by the time we get here and the checks were just ensuring that it was 8 bits. Thus I don't think there's anyway for them to fail. llvm-svn: 322244
* [X86] Allow _mm_prefetch (both the header implementation and the builtin) to ↵Craig Topper2017-12-211-1/+1
| | | | | | | | accept bit 2 which is supposed to indicate the prefetched addresses will be written to Add the appropriate _MM_HINT_ET0/ET1 defines to match gcc. llvm-svn: 321325
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-2/+2
| | | | llvm-svn: 321115
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-141-7/+18
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* Unify implementation of our two different flavours of -Wtautological-compare,Richard Smith2017-12-081-200/+159
| | | | | | | | | | | | | | | | | | | | | | | | | and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
* Revert "Unify implementation of our two different flavours of ↵Hans Wennborg2017-12-081-155/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | -Wtautological-compare." > Unify implementation of our two different flavours of -Wtautological-compare. > > In so doing, fix a handful of remaining bugs where we would report false > positives or false negatives if we promote a signed value to an unsigned type > for the comparison. This caused a new warning in Chromium: ../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64 with expression of type 'unsigned int' is always true [-Werror,-Wtautological-constant-out-of-range-compare] DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize); ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'unsigned int' is really a 6-bit bitfield, which is why it's always less than 64. I thought we didn't use to warn (with out-of-range-compare) when comparing against the boundaries of a type? llvm-svn: 320162
* Revert r320124 "Fold together the in-range and out-of-range portions of ↵Hans Wennborg2017-12-081-35/+98
| | | | | | | | | | | | | | | | | | | | -Wtautological-compare." This broke Chromium: ../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64 with expression of type 'unsigned int' is always true [-Werror,-Wtautological-constant-out-of-range-compare] DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize); ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'unsigned int' is really a 6-bit bitfield, which is why it's always less than 63. Did this use to fall under the "in-range" case before? I thought we didn't use to warn when comparing against the boundaries of a type. llvm-svn: 320133
* Fold together the in-range and out-of-range portions of -Wtautological-compare.Richard Smith2017-12-081-98/+35
| | | | llvm-svn: 320124
* Unify implementation of our two different flavours of -Wtautological-compare.Richard Smith2017-12-081-145/+155
| | | | | | | | In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. llvm-svn: 320122
* [ARM] ACLE parallel arithmetic and DSP style multiplicationsSjoerd Meijer2017-12-071-8/+13
| | | | | | | | | | | This is a follow up of r302131, in which we forgot to add SemaChecking tests. Adding these tests revealed two problems which have been fixed: - added missing intrinsic __qdbl, - properly range checking ssat16 and usat16. Differential Revision: https://reviews.llvm.org/D40888 llvm-svn: 320019
* Ignore pointers to incomplete types when diagnosing misaligned addressesRoger Ferrer Ibanez2017-12-071-2/+3
| | | | | | | | | This is a fix for PR35509 in which we crash because we attempt to compute the alignment of an incomplete type. Differential Revision: https://reviews.llvm.org/D40895 llvm-svn: 320017
* Delete special-case "out-of-range" handling for bools, and just use the normalRichard Smith2017-12-061-115/+61
| | | | | | | | | | | codepath plus the new "minimum / maximum value of type" diagnostic to get the same effect. Move the warning for an in-range but tautological comparison of a constant (0 or 1) against a bool out of -Wtautological-constant-out-of-range-compare into the more-appropriate -Wtautological-constant-compare. llvm-svn: 319942
* Fix a bunch of wrong "tautological unsigned enum compare" diagnostics in C++.Richard Smith2017-12-061-3/+4
| | | | | | | An enumeration with a fixed underlying type can have any value in its underlying type, not just those spanned by the values of its enumerators. llvm-svn: 319875
* Perform a bounds check on a function's argument list before accessing any ↵Aaron Ballman2017-11-291-2/+17
| | | | | | | | index value specified by an 'argument_with_type_tag' attribute. Fixes PR28520. Patch by Matt Davis. llvm-svn: 319383
* Revert r318556 "Loosen -Wempty-body warning"Hans Wennborg2017-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems this somehow made -Wempty-body fire in some macro cases where it didn't before, e.g. ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): error: if statement has empty body [-Werror,-Wempty-body] ff_dlog(NULL, "new table index=%d size=%d\n", table_index, table_size); ^ ../../third_party/ffmpeg\libavutil/internal.h(276,80): note: expanded from macro 'ff_dlog' # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0) ^ ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): note: put the semicolon on a separate line to silence this warning Reverting until this can be figured out. > Do not show it when `if` or `else` come from macros. > E.g., > > #define USED(A) if (A); else > #define SOME_IF(A) if (A) > > void test() { > // No warnings are shown in those cases now. > USED(0); > SOME_IF(0); > } > > Patch by Ilya Biryukov! > > Differential Revision: https://reviews.llvm.org/D40185 llvm-svn: 318665
* Loosen -Wempty-body warningReid Kleckner2017-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | Do not show it when `if` or `else` come from macros. E.g., #define USED(A) if (A); else #define SOME_IF(A) if (A) void test() { // No warnings are shown in those cases now. USED(0); SOME_IF(0); } Patch by Ilya Biryukov! Differential Revision: https://reviews.llvm.org/D40185 llvm-svn: 318556
* [ObjC][ARC] Honor noescape attribute for -Warc-retain-cyclesAlex Lorenz2017-11-171-2/+8
| | | | | | | | rdar://35409566 Differential Revision: https://reviews.llvm.org/D40141 llvm-svn: 318552
* [AST, Sema] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-11-151-174/+275
| | | | | | other minor fixes (NFC). llvm-svn: 318341
* [X86] Add masked vcvtps2ph builtins to CheckX86BuiltinFunctionCall.Craig Topper2017-11-081-0/+3
| | | | | | This ensures that only immediates that fit in 8-bits are used. This matches what we do for the unmasked versions. llvm-svn: 317664
* [Sema] Fixes for enum handling for tautological comparison diagnosticsRoman Lebedev2017-10-211-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should be used when checking for the tautological comparison, unlike C++, where the enumerator values define the value range. So if not in CPlusPlus mode, use the enum underlying type. Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison: ``` enum A { A_a = 0 }; if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}} return 0; ``` This affects both the C and C++, but after the first fix, only C++ code was affected. That was also fixed, while preserving (i think?) the proper diagnostic output. And while there, attempt to enhance the test coverage. Yes, some tests got moved around, sorry about that :) Fixes PR35009 Reviewers: aaron.ballman, rsmith, rjmccall Reviewed By: aaron.ballman Subscribers: Rakete1111, efriedma, materi, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D39122 llvm-svn: 316268
* Sema: use new `getNS{,U}IntegerType` for NS{,U}IntegerSaleem Abdulrasool2017-10-171-3/+3
| | | | | | | | Use the new helper methods to get the underlying type for NSUInteger, NSInteger types. This avoids spreading the knowledge of the underlying types in various sites. For non-LLP64 targets, this has no change. llvm-svn: 316013
* [Sema] Re-land: Diagnose tautological comparison with type's min/max valuesRoman Lebedev2017-10-151-95/+146
| | | | | | | | | | | | | | | | | | | | | | | | | The first attempt, rL315614 was reverted because one libcxx test broke, and i did not know at the time how to deal with it. Summary: Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`), and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the `std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147 Continuation of https://reviews.llvm.org/D37565 Reviewers: rjmccall, rsmith, aaron.ballman Reviewed By: rsmith Subscribers: rtrieu, jroelofs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38101 llvm-svn: 315875
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* Revert "[Sema] Diagnose tautological comparison with type's min/max values"Roman Lebedev2017-10-121-146/+95
| | | | | | | | | | | | | | | | | | | | | This reverts r315614,r315615,r315621,r315622 Breaks http://bb9.pgr.jp/#/builders/20/builds/59 /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare] if (max_sec > Lim::max()) return false; ~~~~~~~ ^ ~~~~~~~~~~ /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare] if (sec < Lim::min() || sec > Lim::max()) return false; ~~~ ^ ~~~~~~~~~~ /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare] if (sec < Lim::min() || sec > Lim::max()) return false; ~~~ ^ ~~~~~~~~~~ 3 errors generated. -- I'm not yet sure what is the proper fix. llvm-svn: 315631
* [SemaChecking] Suppress a GCC warning. NFCI.Davide Italiano2017-10-121-1/+2
| | | | llvm-svn: 315621
* [Sema] Diagnose tautological comparison with type's min/max valuesRoman Lebedev2017-10-121-95/+145
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`), and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the `std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147 Continuation of https://reviews.llvm.org/D37565 Reviewers: rjmccall, rsmith, aaron.ballman Reviewed By: rsmith Subscribers: rtrieu, jroelofs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38101 llvm-svn: 315614
* Consolidate std::move() detection code. No behavior change.Nico Weber2017-09-281-3/+1
| | | | llvm-svn: 314427
* Sema: rename SemaBuiltinVAStart to SemaBuiltinVAStartMicrosoftSaleem Abdulrasool2017-09-261-2/+2
| | | | | | | | | | | This function is used to perform semantic analysis on Microsoft style `__va_start`. Rename it to make this more explicit. `__va_start` is marked as `ALL_MS_LANGUAGES`, and requires Microsoft compatibility. Other GNU targets will use `__builtin_va_start` instead. NFC. Addresses post-commit review comments from David Majnemer. llvm-svn: 314241
OpenPOWER on IntegriCloud