| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Only initialize pointers that can be initialized.
|
|
|
|
(#145014)
…types usi… (#144676)"
This reverts commit 68471d29eed2c49f9b439e505b3f24d387d54f97.
IntegralAP contains a union:
union {
uint64_t *Memory = nullptr;
uint64_t Val;
};
On 64bit systems, both Memory and Val have the same size. However, on 32
bit system, Val is 64bit and Memory only 32bit. Which means the default
initializer for Memory will only zero half of Val. We fixed this by
zero-initializing Val explicitly in the IntegralAP(unsigned BitWidth)
constructor.
See also the discussion in
https://github.com/llvm/llvm-project/pull/144246
|
|
usi… (#144676)"
This reverts commit 7c15edb306932e41c159f3d69c161ed0d89d47b7.
This still breaks clang-armv8-quick:
https://lab.llvm.org/buildbot/#/builders/154/builds/17587
|
|
(#144676)
…ng an allocator (#144246)"
This reverts commit 57828fec760f086b334ce0cb1c465fc559dcaea4.
|
|
allocator (#144246)"
This reverts commit c66be289901b3f035187d391e80e3610d7d6232e.
This breaks the armv8-quick builder:
https://lab.llvm.org/buildbot/#/builders/154/builds/17549
|
|
(#144246)
Both `APInt` and `APFloat` will heap-allocate memory themselves using
the system allocator when the size of their data exceeds 64 bits.
This is why clang has `APNumericStorage`, which allocates its memory
using an allocator (via `ASTContext`) instead. Calling `getValue()` on
an ast node like that will then create a new `APInt`/`APFloat` , which
will copy the data (in the `APFloat` case, we even copy it twice).
That's sad but whatever.
In the bytecode interpreter, we have a similar problem. Large integers
and floating-point values are placement-new allocated into the
`InterpStack` (or into the bytecode, which is a `vector<std::byte>`).
When we then later interrupt interpretation, we don't run the destructor
for all items on the stack, which means we leak the memory the
`APInt`/`APFloat` (which backs the `IntegralAP`/`Floating` the
interpreter uses).
Fix this by using an approach similar to the one used in the AST. Add an
allocator to `InterpState`, which is used for temporaries and local
values. Those values will be freed at the end of interpretation. For
global variables, we need to promote the values to global lifetime,
which we do via `InitGlobal` and `FinishInitGlobal` ops.
Interestingly, this results in a slight _improvement_ in compile times:
https://llvm-compile-time-tracker.com/compare.php?from=6bfcdda9b1ddf0900f82f7e30cb5e3253a791d50&to=88d1d899127b408f0fb0f385c2c58e6283195049&stat=instructions:u
(but don't ask me why).
Fixes https://github.com/llvm/llvm-project/issues/139012
|
|
|
|
The outermost function doesn't have a This pointers, but inner calls
can. This still doesn't match the diagnostic output of the current
interpreter properly, but it's closer I think.
|
|
We have to copy the entire thing, not just one of the bases.
|
|
Add a test for type punning and tests and the necessary checks for
non-trivially-copyable types and incomplete types.
|
|
|
|
So the diagnostic output matches with the current interpreter
|
|
(#132963)
…723)"
This reverts commit 1e2ad6793ac205607e7c809283cf69e1cc36a69a.
Fix the previous commit on big-endian hosts by _not_ falling through to
the `uint8_t` code path.
|
|
This reverts commit f7aea4d081f77dba48b0fc019f59b678fb679aa8.
This broke the clang-solaris11-sparcv9 builder:
https://lab.llvm.org/buildbot/#/builders/13/builds/6151
|
|
Make sure we run each configuration once with the bytecode interpreter
and once with the current one. Add a triple to the one that was
previously without.
|
|
|
|
Like the current interpreter does.
|
|
This is already almost implemented, just need to enable support for it.
|
|
Unfortunately, a few circumstances make the implementation here less
than ideal, but we need to handle overlapping regions anyway.
|
|
|
|
|
|
When such a pointer is heap allocated, the type we get is a pointer
type. Take the pointee type in that case.
|
|
llvm has recently started to use `__builitn_memchr` at compile time, so
implement this. Still needs some work but the basics are done.
|
|
Try to dig out the call expression and diagnose this as an opaque call.
|
|
This is what the current interpreter does as well.
|
|
Reduced from
libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/move.pass.cpp
|
|
... between unrelated declarations or literals.
Leaving this small (I haven't run the whole test suite locally) to get
some feedback on the wording and implementation first.
The output of the sample in
https://github.com/llvm/llvm-project/issues/117409 is now:
```console
./array.cpp:57:6: warning: expression result unused [-Wunused-value]
57 | am - aj.af();
| ~~ ^ ~~~~~~~
./array.cpp:70:8: error: call to consteval function 'L::L<bx>' is not a constant expression
70 | q(0, [] {
| ^
./array.cpp:57:6: note: arithmetic on addresses of literals has unspecified value
57 | am - aj.af();
| ^
./array.cpp:62:5: note: in call to 'al(&""[0], {&""[0]})'
62 | al(bp.af(), k);
| ^~~~~~~~~~~~~~
./array.cpp:70:8: note: in call to 'L<bx>({})'
70 | q(0, [] {
| ^~~~
71 | struct bx {
| ~~~~~~~~~~~
72 | constexpr operator ab<g<l<decltype(""[0])>::e>::e>() { return t(""); }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 | };
| ~~
74 | return bx();
| ~~~~~~~~~~~~
75 | }());
| ~~~
```
The output for
```c++
int a, b;
constexpr int n = &b - &a
```
is now:
```console
./array.cpp:80:15: error: constexpr variable 'n' must be initialized by a constant expression
80 | constexpr int n = &b - &a;
| ^ ~~~~~~~
./array.cpp:80:22: note: arithmetic involving '&b' and '&a' has unspecified value
80 | constexpr int n = &b - &a;
| ^
1 error generated.
```
|
|
When emitting diagnostics for the number of elements.
|
|
... elements.
|
|
Both destination and source pointer need to have at least as many
elements as requested.
|
|
Unfortunately, that means we can't use the __builtin_bit_cast
implementation for this.
|
|
|
|
... the same as `__builtin_memcmp`. Also fix a bug we still had when we
couldn't find a difference in the two inputs after `Size` bytes.
|
|
|
|
|
|
... in checkingPotentialConstantExpression mode. This is what the
current interpreter does, yet it doesn't do so for
`__builtin_operator_new`.
|
|
|
|
|
|
Handle different char widths in builtin_strlen.
|
|
To DoBitCastPtr, so we know how many bytes we want to read.
|
|
This reverts commit 89a0ee89973c3d213c4bc11c26b41eab67e06da0.
This breaks builders:
https://lab.llvm.org/buildbot/#/builders/13/builds/3885
|
|
To match the diagnostic output of the current interpreter.
|
|
(#118457)
|
|
... just like strlen.
|
|
This is the same thing for us, except for diagnostic differences.
|
|
|
|
|
|
|
