No test because I'm not sure how to reproduce this, but this patch fixes
`CodeGen/ptrauth-qualifier-function.c`.
For function pointer types and function reference types, we use
`Pointer`s these days, so we _can_ return them.
tryEvaluateString was returning an std::optional, but the other try* API
was not. Update tryEvaluateObjectSize and tryEvaluateStrLen to return an
std::optional<uint64_t>.
This only calls `noteStep()` on jump opcodes, so this works for loops.
It does not prevent "hangs" when a function is just _very_ long (could
be interesting how this interfaces with expand statements?).
Fixes https://github.com/llvm/llvm-project/issues/165951
Before this patch, reading union template parameter object will trigger
diagnostics saying it's not initialized. This patch fixes this issue.
Reading union template parameter with no active fields, class type
fields, or bit-fields is handled as a drive-by.
AI usage: The implementation was generated by AI and modified by me
afterwards.
Assisted-by: GPT-5.2
---------
Co-authored-by: Timm Baeder <tbaeder@redhat.com>
The bytecode compiler was ignoring the DiscardResult flag in
VisitPointerArithBinOp
, causing pointer addition and subtraction results to persist on the
stack when they should have been popped (e.g., in comma expressions).
This led to stack corruption and assertion failures in subsequent
operations that encountered an unexpected pointer on the stack.
This patch refactors the unified addition/subtraction logic to ensure
the result is properly popped when DiscardResult is true.
Fixes#176549
There are situations where DiscardResult is set, but we still wish to
emit a float value, e.g. when we will discard the result of an operation
involving such a float value.
## Summary
When dereferencing a pointer that was `reinterpret_cast` to a larger
type (e.g. `*(int**)""`), the bytecode interpreter would crash with an
assertion failure because it tried to read more bytes than the
allocation contained.
## Changes
- Add a size check in `Pointer::toRValue()` before calling `deref<T>()`
to ensure the allocation is large enough
- If the allocation is too small, return `std::nullopt` to gracefully
fail the constant evaluation instead of crashing
- Add regression test
Fixes#179015
## Summary
- Fix crash when passing non primitive types (structs) to
`__builtin_infer_alloc_token`
- The bytecode interpreter's discard loop dereferenced an empty
`OptPrimType` for non primitive arguments
## Test plan
- Added regression test in `clang/test/SemaCXX/alloc-token.cpp`
- Existing tests continue to pass
Fixes#178892
This is like https://github.com/llvm/llvm-project/pull/179033, which
broke a few builders for reasons I still don't really understand. I ran
the other clang tests and this version fixes a few of the introduced
regressions.
This still regresses `CodeGen/pass-object-size.c`, but that's a
pre-existing issue.
Patch is of coursed based on #179033 by @mariusdr.
Fixes#138474
Use new bytecode intepreter in `Expr::tryEvaluateObjectSize`. Reuses the
already existing implementation for `__builtin_object_size` in of the
intepreter.
---------
Co-authored-by: Timm Baeder <tbaeder@redhat.com>
## Summary
Fix assertion failure when evaluating
`__builtin_align_up`/`__builtin_align_down`/`__builtin_is_aligned` with
one-past-end pointers like `&array[size]`.
## Root Cause
`getIndex()` calls `getOffset()` which asserts when `Offset ==
PastEndMark`. This happens for one-past-end element pointers.
## Fix
Check `isElementPastEnd()` before calling `getIndex()`. For past-end
pointers, use `getNumElems()` instead which gives the correct index
value.
## Test
Added test cases in `builtin-align-cxx.cpp` for one-past-end pointer
alignment.
Fixes#178647
Update the callback signature for `EvaluateFpBinOpExpr` and
`interp__builtin_elementwise_fp_binop` to return
`std::optional<APFloat>`, allowing individual callbacks to decide
whether to handle special floating-point cases (inf/nan/denormal).
Previously, the helper functions had hardcoded validation that forced
all callbacks to reject these cases. This blocked intrinsics needing
custom validation (e.g., rounding mode checks). Now each callback
controls its own validation and returns `std::nullopt` when the fold is
invalid.
Fixes#178416
The bytecode compiler was incorrectly emitting an
RVOPtr
opcode for void functions if the return expression had a non-void type
(e.g. from a conditional operator). This triggered an assertion in the
interpreter because void functions lack RVO metadata.
This patch updates
visitReturnStmt
to check the function’s return type and use
discard()
for the expression in void contexts, preventing erroneous RVO pathing.
Fixes#176536
### What the problem ?
Fix a clang bytecode constant interpreter crash when evaluating
wcslen("x") in a constant-expression path.
Previously we asserted on wchar element size mismatch and crashed in
assertion builds.
### Why it happened
The expression is already ill-typed (char[2] → const wchar_t*), clang
correctly emits a diagnostic, but later ICE checking tries to fold the
expression and reaches the builtin handler. That path must not crash.
### whats the Fix
Replace the assert(ElemSize == wchar_t size) with a graceful failure
(return false / emit appropriate diagnostic) when element sizes don’t
match, so evaluation stops safely.
### how to Test it
Add a regression test that triggers ICE checking with
-fexperimental-new-constant-interpreter and ensures clang does not crash
(verifies it reports the type error / static_assert failure instead).
Fixes#177844.
<img width="1366" height="768" alt="Screenshot_2026-01-25_22_07_50"
src="https://github.com/user-attachments/assets/488dd0b0-3c17-4f45-b2d0-9339b8fd3409"
/>
where wclen_crash.c is
`
#include <wchar.h>
static_assert(wcslen("x") == 'x');
int main() {}
`
---------
Co-authored-by: Timm Baeder <tbaeder@redhat.com>
Before this PR evaluation process will stop immediately regradless of
whether it's set to handle overflow,
this will prevent us getting value from stack, which leads to crash(with
or without assertion).
Closes #177751.
Fixes llvm#176902: [clang][bytecode] crashes on ill-formed
_Static_assert comparing complex value
This patch resolves a crash in Clang's constant evaluation when handling
complex number comparisons in discarded expressions, such as those
involving short-circuiting logical operators. The crash occurred due to
unnecessary evaluation of the comparison in the experimental constant
interpreter.
The issue was originally observed and minimized in the following
example:
```cpp
#define EVAL(a, b) _Static_assert(a == b, "")
void foo() {
EVAL(; + 0, 1i);
}
```
This patch ensures that such comparisons are handled correctly without
triggering assertions when the result is discarded.
Tests
A regression test has been added to verify that complex comparisons in
discarded expressions no longer cause crashes during constant
evaluation.
Local verification:
llvm-project-main/clang/lib/AST/ByteCode/constant-eval-complex-discard.c
passes.
Full ninja check-clang may fail locally due to a known GCC ICE when
building Clang unittests; this is unrelated to the change itself.
