Just ignore it.
As part of this, move the Ret and RetVoid implementation to Interp.h, so
they can be shared with InterpBuiltin.cpp.
Differential Revision: https://reviews.llvm.org/D141193
We were just casting to `unsigned` before, so that caused problems when
shifting more bits than `unsigned` has.
Differential Revision: https://reviews.llvm.org/D140845
There was a FIXME comment for this. Stop getting the values in
OffsetHelper and let the caller do that instead, so we can control
whether the value(s) are removed from the stack at all.
Also use ArithOp instead of the unclear boolean for Add.
We need to run the functions we compiled immediately after to check if
they can ever be a constant expression.
Differential Revision: https://reviews.llvm.org/D140724
Use an InlineDescriptor per local variable to track whether locals
have been initialized or not. This way we can support uninitialized
local variables in constexpr functions.
Differential Revision: https://reviews.llvm.org/D135750
The calling convention is:
[RVO pointer]
[instance pointer]
[... args ...]
We handle the instance pointer ourselves, BUT for the RVO pointer, we
just assumed in visitReturnStmt() that it is on top of the stack. Which
isn't true if there are other args present (and a this pointer, maybe).
Fix this by recording the RVO pointer explicitly when creating an
InterpFrame, just like we do with the instance/This pointer.
There is already a "RVOAndParams()" test in test/AST/Inter/records.cpp,
that was supposed to test this, however, it didn't trigger any
problematic behavior because the parameter and the return value have the
same type.
Differential Revision: https://reviews.llvm.org/D137392
This was confusing. InitElem peeks a pointer, while InitElemPop will
pop the pointer. However, for fields, InitField would pop the pointer
and no InitFieldPop exists. At least make InitField and InitElem behave
the same.
When assigning to them, we can't classify the expression type, because
that doesn't contain the right information.
And when reading from them, we need to do the extra deref, just like we
do when reading from a DeclRefExpr.
Differential Revision: https://reviews.llvm.org/D136012
Remove the double Call() implementation to reduce code duplication. Then
fix Function::getSource() so we can diagnose instance pointers being
null.
Differential Revision: https://reviews.llvm.org/D135513
Implement negating and inverting values. Also implement
IntegralToBoolean casts so the operations are easier to test.
Differential Revision: https://reviews.llvm.org/D132098
The Clang interpreter's bytecode uses a packed stream of bytes
representation, but also wants to have some opcodes take pointers as
arguments, which are currently embedded in the bytecode directly.
However, CHERI, and thus Arm's upcoming experimental Morello prototype,
provide spatial memory safety for C/C++ by implementing language-level
(and sub-language-level) pointers as capabilities, which track bounds,
permissions and validity in hardware. This uses tagged memory with a
single tag bit at every capability-aligned address, and so storing
pointers to unaligned addresses results in the tag being stripped,
leading to a tag fault when the pointer is ultimately dereferenced at a
later point.
In order to support a stricter C/C++ implementation like CHERI, we no
longer store pointers directly in the bytecode, instead storing them in
a table and embedding the index in the bytecode.
Reviewed By: nand
Differential Revision: https://reviews.llvm.org/D97606
