summaryrefslogtreecommitdiffstats
path: root/include/clang/Basic/DiagnosticASTKinds.td
Commit message (Collapse)AuthorAgeFilesLines
* Fix up diagnostics.Richard Trieu2018-12-141-0/+30
| | | | | | | | | | | | Move some diagnostics around between Diagnostic*Kinds.td files. Diagnostics used in multiple places were moved to DiagnosticCommonKinds.td. Diagnostics listed in the wrong place (ie, Sema diagnostics listed in DiagnosticsParseKinds.td) were moved to the correct places. One diagnostic split into two so that the diagnostic string is in the .td file instead of in code. Cleaned up the diagnostic includes after all the changes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349125 91177308-0d34-0410-b5e6-96231b3b80d8
* [ExprConstant] Improve memchr/memcmp for type mismatch and multibyte element ↵Hubert Tong2018-12-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | types Summary: `memchr` and `memcmp` operate upon the character units of the object representation; that is, the `size_t` parameter expresses the number of character units. The constant folding implementation is updated in this patch to account for multibyte element types in the arrays passed to `memchr`/`memcmp` and, in the case of `memcmp`, to account for the possibility that the arrays may have differing element types (even when they are byte-sized). Actual inspection of the object representation is not implemented. Comparisons are done only between elements with the same object size; that is, `memchr` will fail when inspecting at least one character unit of a multibyte element. The integer types are assumed to have two's complement representation with 0 for `false`, 1 for `true`, and no padding bits. `memcmp` on multibyte elements will only be able to fold in cases where enough elements are equal for the answer to be 0. Various tests are added to guard against incorrect folding for cases that miscompile on some system or other prior to this patch. At the same time, the unsigned 32-bit `wchar_t` testing in `test/SemaCXX/constexpr-string.cpp` is restored. Reviewers: rsmith, aaron.ballman, hfinkel Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55510 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348938 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Fix ICE when memcpy() is given a pointer to an incomplete arrayPetr Pavlu2018-10-041-0/+3
| | | | | | | | | | | Fix code for constant evaluation of __builtin_memcpy() and __builtin_memmove() that would attempt to divide by zero when given two pointers to an incomplete array. Differential Revision: https://reviews.llvm.org/D51855 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343761 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix crash on call to __builtin_memcpy with a null pointer to anRichard Smith2018-09-131-0/+4
| | | | | | | | incomplete type. Also improve the diagnostics for similar situations. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@342192 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-08-041-0/+14
| | | | | | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. This reinstates r338455, reverted in r338602, with a fix to avoid trying to constant-evaluate a memcpy call if either pointer operand has an invalid designator. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338941 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r338455 "[constexpr] Support for constant evaluation of ↵Hans Wennborg2018-08-011-14/+0
| | | | | | | | | | | | | | | | __builtin_memcpy and __builtin_memmove (in non-type-punning cases)." It caused asserts during Chromium builds, see reply on the cfe-commits thread. > This is intended to permit libc++ to make std::copy etc constexpr > without sacrificing the optimization that uses memcpy on > trivially-copyable types. > > __builtin_strcpy and __builtin_wcscpy are not handled by this change. > They'd be straightforward to add, but we haven't encountered a need for > them just yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338602 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-07-311-0/+14
| | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338455 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338291 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter] FriendDecl importing improvementsPeter Szecsi2018-04-251-0/+2
| | | | | | | | | | | | There are only a few cases of importing a frienddecl which is currently supported. This patch aims to improve the friend import process. Set FriendObjectKind in case of decls, insert friend into the friend chain correctly, checks structurally equivalent in a more advanced manner. Test cases added as well. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@330847 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement current CWG direction for support of arrays of unknown bounds inRichard Smith2017-10-201-0/+9
| | | | | | | | | | | | | | | | | | constant expressions. We permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). This is based on r311970 and r301822 (the former by me and the latter by Robert Haberlach). Between then and now, two things have changed: we have committee feedback indicating that this is indeed the right direction, and the code broken by this change has been fixed. This is necessary in C++17 to continue accepting certain forms of non-type template argument involving arrays of unknown bound. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316245 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Improve constant expression evaluation of arrays of unknown bound."Martin Bohme2017-08-301-9/+0
| | | | | | | | This reverts commit r311970. Breaks internal tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312108 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve constant expression evaluation of arrays of unknown bound.Richard Smith2017-08-291-0/+9
| | | | | | | | | The standard is not clear on how these are supposed to be handled, so we conservatively treat as non-constant any cases whose value is unknown or whose evaluation might result in undefined behavior. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311970 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306918 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r301822 (and dependent r301825), which tried to improve theDaniel Jasper2017-05-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | handling of constexprs with unknown bounds. This triggers a corner case of the language where it's not yet clear whether this should be an error: struct A { static void *const a[]; static void *const b[]; }; constexpr void *A::a[] = {&b[0]}; constexpr void *A::b[] = {&a[0]}; When discovering the initializer for A::a, the bounds of A::b aren't known yet. It is unclear whether warning about errors should be deferred until the end of the translation unit, possibly resolving errors that can be resolved. In practice, the compiler can know the bounds of all arrays in this example. Credits for reproducers and explanation go to Richard Smith. Richard, please add more info in case my explanation is wrong. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301963 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve handling of arrays of unknown bound in constant expressions.Richard Smith2017-05-011-1/+3
| | | | | | | | | | | | | | | Do not spuriously reject constexpr functions that access elements of an array of unknown bound; this may later become valid once the bound is known. Permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). The standard is not clear on how this should work, but this seems to be a decent answer. Patch by Robert Haberlach! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301822 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve fix for PR28739Richard Smith2017-01-311-1/+2
| | | | | | | | | | | | | | | | Don't try to map an APSInt addend to an int64_t in pointer arithmetic before bounds-checking it. This gives more consistent behavior (outside C++11, we consistently use 2s complement semantics for both pointer and integer overflow in constant expressions) and fixes some cases where in C++11 we would fail to properly check for out-of-bounds pointer arithmetic (if the 2s complement 64-bit overflow landed us back in-bounds). In passing, also fix some cases where we'd perform possibly-overflowing arithmetic on CharUnits (which have a signed underlying type) during constant expression evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293595 91177308-0d34-0410-b5e6-96231b3b80d8
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8
* [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier ↵Faisal Vali2016-03-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264513 91177308-0d34-0410-b5e6-96231b3b80d8
* [MS ABI] Detect and diagnose vftables which cannot be createdDavid Majnemer2015-05-011-0/+8
| | | | | | | | | | | | | | | | The MSVC ABI has a bug introduced by appending to the end of vftables which come from virtual bases: covariant thunks introduces via non-overlapping regions of the inheritance lattice both append to the same slot in the vftable. It is possible to generate correct vftables in cases where one node in the lattice completely dominates the other on the way to the base with the vfptr; in all other cases, we must raise a diagnostic in order to prevent the illusion that we succeeded in laying out the vftable. This fixes PR16759. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236354 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr evaluation for __builtin_assume_alignedHal Finkel2014-10-031-0/+7
| | | | | | | | | | | | | | | | | Richard noted in the review of r217349 that extra handling of __builtin_assume_aligned inside of the expression evaluator was needed. He was right, and this should address the concerns raised, namely: 1. The offset argument to __builtin_assume_aligned can have side effects, and we need to make sure that all arguments are properly evaluated. 2. If the alignment assumption does not hold, that introduces undefined behavior, and undefined behavior cannot appear inside a constexpr. and hopefully the diagnostics produced are detailed enough to explain what is going on. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218992 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an explicit diagnostic for the case where an expression is not a constantRichard Smith2014-07-071-0/+4
| | | | | | | expression because it uses 'this'. Inspired by PR20219 comment#2. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212433 91177308-0d34-0410-b5e6-96231b3b80d8
* PR5683: Issue a warning when subtracting pointers to types of zero size, andRichard Smith2013-09-101-0/+2
| | | | | | | | treat such subtractions as being non-constant. Patch by Serge Pavlov! With a few tweaks by me. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190439 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: track object lifetime during constexpr evaluation, and don't allowRichard Smith2013-07-241-0/+3
| | | | | | | | objects to be used once their lifetimes end. This completes the C++1y constexpr extensions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187025 91177308-0d34-0410-b5e6-96231b3b80d8
* PR16377: Allow evaluation of statement expressions in constant evaluation,Richard Smith2013-06-201-1/+4
| | | | | | | why not. Apparently GCC supports this. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184396 91177308-0d34-0410-b5e6-96231b3b80d8
* PR14503: Don't assert if a constexpr constructor temploid instantiates to aRichard Smith2013-06-181-0/+2
| | | | | | | | constructor that does not initialize all members, and that constructor is used to initialize a global. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184211 91177308-0d34-0410-b5e6-96231b3b80d8
* Model temporary lifetime-extension explicitly in the AST. Use this model toRichard Smith2013-06-051-0/+4
| | | | | | | | | | handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183283 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: Add a step limit to constexpr evaluation, to catch runaway loops.Richard Smith2013-05-081-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181388 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: support for increment and decrement in constant expression evaluation.Richard Smith2013-05-051-13/+13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181173 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: support simple variable assignments in constexpr functions.Richard Smith2013-04-261-13/+27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180603 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y constexpr extensions, round 1: Allow most forms of declaration andRichard Smith2013-04-221-0/+2
| | | | | | | | | statement in constexpr functions. Everything which doesn't require variable mutation is also allowed as an extension in C++11. 'void' becomes a literal type to support constexpr functions which return 'void'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180022 91177308-0d34-0410-b5e6-96231b3b80d8
* Add space after ';'.Fariborz Jahanian2013-01-251-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173462 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve diagnsotic further on integer overflow.Fariborz Jahanian2013-01-251-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173461 91177308-0d34-0410-b5e6-96231b3b80d8
* Fixes text of diagnostics in integer overflow patch.Fariborz Jahanian2013-01-241-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173388 91177308-0d34-0410-b5e6-96231b3b80d8
* Patch to check for integer overflow. It has beenFariborz Jahanian2013-01-241-0/+3
| | | | | | | commented on and approved by Richard Smith. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173377 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix code that attempted to produce a diagnostic with one DiagnosticEngine, thenRichard Smith2012-12-201-1/+2
| | | | | | | | | produce a note for that diagnostic either with a different DiagnosticEngine or after calling DiagnosticEngine::Reset(). That didn't make any sense, and did the wrong thing if the original diagnostic was suppressed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170636 91177308-0d34-0410-b5e6-96231b3b80d8
* Normalize line endings of r163013 (part 2).Joao Matos2012-08-311-7/+7
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163032 91177308-0d34-0410-b5e6-96231b3b80d8
* Improved MSVC __interface support by adding first class support for it, ↵Joao Matos2012-08-311-7/+7
| | | | | | instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163013 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove hacky temporary fix of r151585.Argyrios Kyrtzidis2012-03-151-5/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152818 91177308-0d34-0410-b5e6-96231b3b80d8
* When evaluating integer expressions include a check for sub-expressionsArgyrios Kyrtzidis2012-02-271-0/+5
| | | | | | | | depth and error if we exceed a max value, to make sure we avoid a stack overflow. This is a hacky temporary fix. rdar://10913206. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151585 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement constant expression support for __real__ and __imag__ on lvalueRichard Smith2012-02-181-2/+4
| | | | | | | | | | | | | | | | complex numbers. Treat complex numbers as arrays of the corresponding component type, in order to make std::complex behave properly if implemented in terms of _Complex T. Apparently libstdc++'s std::complex is implemented this way, and we were rejecting a member like this: constexpr double real() { return __real__ val; } because it was marked constexpr but unable to produce a constant expression. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150895 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr tidyups:Richard Smith2012-02-161-0/+3
| | | | | | | | | * Fix bug when determining whether && / || are potential constant expressions * Try harder when determining whether ?: is a potential constant expression * Produce a diagnostic on sizeof(VLA) to provide a better source location git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150657 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement DR1454. This allows all intermediate results in constant expressionsRichard Smith2012-02-151-3/+5
| | | | | | | | | | | | | to be core constant expressions (including pointers and references to temporaries), and makes constexpr calculations Turing-complete. A Turing machine simulator is included as a testcase. This opens up the possibilty of removing CCValue entirely, and removing some copies from the constant evaluator in the process, but that cleanup is not part of this change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150557 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused diagnostics from include/clang/Basic/Diagnostic*.td files.Dmitri Gribenko2012-02-131-6/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150409 91177308-0d34-0410-b5e6-96231b3b80d8
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-0/+5
| | | | | | | | | | | | | | | | | | | | | 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150359 91177308-0d34-0410-b5e6-96231b3b80d8
* Update to new resolution for DR1458. When taking the address of an object ofRichard Smith2012-02-101-3/+0
| | | | | | | | incomplete class type which has an overloaded operator&, it's now just unspecified whether the overloaded operator or the builtin is used. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150234 91177308-0d34-0410-b5e6-96231b3b80d8
* CWG issue 1405: mutable members are allowed in literal types, but can't undergoRichard Smith2012-02-091-0/+2
| | | | | | | lvalue-to-rvalue conversions in constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150145 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement DR1458: Taking the address of an object of incomplete class type isRichard Smith2012-02-081-0/+3
| | | | | | | | not a constant expression, because we can't tell whether the complete class type will have an overloaded operator&. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150066 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement the agreed resolution to DR1457: a signed left shift of a 1 bit intoRichard Smith2012-02-081-0/+1
| | | | | | | | | | | the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit out of the sign bit still does. As promised to Howard :) The suppression of the potential constant expression checking in system headers is also removed, since the problem it was working around is gone. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150059 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr:Richard Smith2012-02-021-0/+11
| | | | | | | | * support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11 * check for unspecified values in pointer comparisons and pointer subtractions git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149578 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: overflow checking for integral and floating-point arithmetic.Richard Smith2012-02-011-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149473 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 08:41:10 +0000