summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/builtin-constant-p.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+5
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-5/+0
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+5
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* Disallow the operand of __builtin_constant_p from modifying enclosingRichard Smith2019-05-041-0/+71
| | | | | | | | | | | | | | state when it's encountered while evaluating a constexpr function. We attempt to follow GCC trunk's behavior here, but it is somewhat inscrutible, so our behavior is only approximately the same for now. Specifically, we only permit modification of objects whose lifetime began within the operand of the __builtin_constant_p. GCC appears to have effectively the same restriction, but also some unknown restriction based on where and how the local state of the constexpr function is mentioned within the operand (see added testcases). llvm-svn: 359958
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-271-0/+61
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-271-61/+0
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* Fix interactions between __builtin_constant_p and constexpr to matchRichard Smith2019-04-241-0/+61
current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359059
OpenPOWER on IntegriCloud