This is a follow-up to 2e275e24355cb224981f9beb2b026a3169fc7232 and
1395cde24b3641e284bb1daae7d56c189a2635e3 which corrects a missed case:
initializing an _Atomic(T *) from a null pointer constant in the form
of the integer literal 0.
Fixes https://github.com/llvm/llvm-project/issues/63550
Differential Revision: https://reviews.llvm.org/D154284
This patch makes the display of member function calls more true to the user-written code by making use of the syntactical structure of the function calls.
This patch also changes the display of conventional value-based printing from arrow operator to dot operator.
This avoids the syntactical invalidness in notes previously caused by the display of & operator
(lack of parentheses and reference of rvalue)
Fixes https://github.com/llvm/llvm-project/issues/57081
Reviewed By: cjdb
Differential Revision: https://reviews.llvm.org/D151720
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
A new builtin function __builtin_isfpclass is added. It is called as:
__builtin_isfpclass(<floating point value>, <test>)
and returns an integer value, which is non-zero if the floating point
argument falls into one of the classes specified by the second argument,
and zero otherwise. The set of classes is an integer value, where each
value class is represented by a bit. There are ten data classes, as
defined by the IEEE-754 standard, they are represented by bits:
0x0001 (__FPCLASS_SNAN) - Signaling NaN
0x0002 (__FPCLASS_QNAN) - Quiet NaN
0x0004 (__FPCLASS_NEGINF) - Negative infinity
0x0008 (__FPCLASS_NEGNORMAL) - Negative normal
0x0010 (__FPCLASS_NEGSUBNORMAL) - Negative subnormal
0x0020 (__FPCLASS_NEGZERO) - Negative zero
0x0040 (__FPCLASS_POSZERO) - Positive zero
0x0080 (__FPCLASS_POSSUBNORMAL) - Positive subnormal
0x0100 (__FPCLASS_POSNORMAL) - Positive normal
0x0200 (__FPCLASS_POSINF) - Positive infinity
They have corresponding builtin macros to facilitate using the builtin
function:
if (__builtin_isfpclass(x, __FPCLASS_NEGZERO | __FPCLASS_POSZERO) {
// x is any zero.
}
The data class encoding is identical to that used in llvm.is.fpclass
function.
Differential Revision: https://reviews.llvm.org/D152351
When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:
v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^
This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152788
This patch uses cast instead of dyn_cast which will assert if the type doesn't match.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151469
As reported by @kees, GCC treats __builtin_object_size of structures
containing flexible array members (aka arrays with incomplete type) not
just as the sizeof the underlying type, but additionally the size of the
members in a designated initializer list.
Fixes: https://github.com/llvm/llvm-project/issues/62789
Reviewed By: erichkeane, efriedma
Differential Revision: https://reviews.llvm.org/D150892
Reported by Static Code Analyzer Tool, Coverity:
Dereference null return value
Inside "ExprConstant.cpp" file, in <unnamed>::RecordExprEvaluator::VisitCXXStdInitializerListExpr(clang::CXXStdInitializerListExpr const *): Return value of function which returns null is dereferenced without checking.
bool RecordExprEvaluator::VisitCXXStdInitializerListExpr(
const CXXStdInitializerListExpr *E) {
// returned_null: getAsConstantArrayType returns nullptr (checked 81 out of 93 times).
//var_assigned: Assigning: ArrayType = nullptr return value from getAsConstantArrayType.
const ConstantArrayType *ArrayType =
Info.Ctx.getAsConstantArrayType(E->getSubExpr()->getType());
LValue Array;
//Condition !EvaluateLValue(E->getSubExpr(), Array, this->Info, false), taking false branch.
if (!EvaluateLValue(E->getSubExpr(), Array, Info))
return false;
// Get a pointer to the first element of the array.
//Dereference null return value (NULL_RETURNS)
//dereference: Dereferencing a pointer that might be nullptr ArrayType when calling addArray.
Array.addArray(Info, E, ArrayType);
This patch adds an assert for unexpected type for array initializer.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151040
As reported by @kees, GCC treats __builtin_object_size of structures
containing flexible array members (aka arrays with incomplete type) not
just as the sizeof the underlying type, but additionally the size of the
members in a designated initializer list.
Fixes: https://github.com/llvm/llvm-project/issues/62789
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D150892
This reverts commit 0e167fc0a2147c9b673b8afd5fea001b0d127781.
This patch causes its assertion to fire when doing AST-dump, so
reverting so that the author has time to fix this.
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
This amends 2e275e24355cb224981f9beb2b026a3169fc7232. That commit added
a null to pointer cast kind when determining whether the expression can
be a valid constant initializer, but failed to update the constant
expression evaluator to perform the evaluation. This commit updates the
constant expression evaluator to handle that cast kind.
This patch fixes the wrong signal from the constexpr evaluator that
[[gnu::weak]] member pointer comparison is valid, while it is emitting
notes on them.
I found a crashing case fixed by this change and added it as a test
case: https://godbolt.org/z/8391fGjGn
I noticed this while I was working on D146358.
Differential Revision: https://reviews.llvm.org/D148419
This patch improves diagnostic for clang constexpr evaluator by adding
a check for nullptr in function pointer call evaluations.
ex.
```
constexpr int foo(int (*bla)(void)) {
return bla();
}
static_assert(foo(nullptr) == 1);
```
BEFORE this patch, clang generates the following diagnostic for the
code above:
```
<source>:5:15: error: static assertion expression is not an integral constant expression
static_assert(foo(nullptr) == 1);
^~~~~~~~~~~~~~~~~
<source>:2:10: note: subexpression not valid in a constant expression
return bla();
^
<source>:5:15: note: in call to 'foo(nullptr)'
static_assert(foo(nullptr) == 1);
^
1 error generated.
```
AFTER this patch, subexpression not valid in a constant expression note
is replaced with 'bla' evaluates to a null function pointer.
Fixes https://github.com/llvm/llvm-project/issues/59872
Differential Revision: https://reviews.llvm.org/D145793
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Differential Revision: https://reviews.llvm.org/D122215
This diff extends D123345 by adding support for std::forward_like.
Test plan: ninja check-clang check-clang-tools check-llvm
Differential revision: https://reviews.llvm.org/D142430
FastEvaluateAsRValue returns `true` without setting a result value for when a
given constant expression is an array or record type.
Clang attributes must be able to support constant expressions that are array or
record types, so proceed with the slower path for evaluation in the case where
`FastEvaluateAsRValue` does not yield an evaluation result.
Differential Revision: https://reviews.llvm.org/D141745
This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.
The relanded commits are:
* 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from
a parenthesized list of values
* c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic
* 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode
This patch also fixes a crash in the original implementation.
Previously, if the input tried to call an implicitly deleted copy or
move constructor of a union, we would then try to initialize the union
by initializing it's first element with a reference to a union. This
behavior is incorrect (we should fail to initialize) and if the type of
the first element has a constructor with a single template typename
parameter, then Clang will explode. This patch fixes that issue by
checking that constructor overload resolution did not result in a
deleted function before attempting parenthesized aggregate
initialization.
Additionally, this patch also includes D140159, which contains some
minor fixes made in response to code review comments in the original
implementation that were made after that patch was submitted.
Co-authored-by: Sheng <ox59616e@gmail.com>
Fixes#54040, Fixes#59675
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D141546
Currently we don't diagnose overflow in a constant expression for the case of
compound assignment with remainder as a operand.
In handleIntIntBinOp the arguments LHS and Result can be the same source but in
the check for remainder in this function we assigned to Result before checking
for overflow. In all the other operations the check is done before Result is
assigned to.
Differential Revision: https://reviews.llvm.org/D140455
Fix an edge case `ExprConstant.cpp`'s `EvaluateWithSubstitution` when called by `CheckEnableIf`
The assertion in `CallStackFrame::getTemporary`
could fail during evaluation of nested calls to a function
using `enable_if` when the second argument was a
value-dependent expression.
This caused a temporary to be created for the second
argument with a given version during the
evaluation of the inner call, but we bailed out
when evaluating the second argument of the
outer call due to the expression being value-dependent.
After bailing out, we tried to clean up the argument's value slot but it
caused an assertion to trigger in `getTemporary` as
a temporary for the second argument existed, but only for the inner call and not the outer call.
See the test case for a more complete description of the issue.
Reviewed By: ahatanak
Differential Revision: https://reviews.llvm.org/D139713
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
