[daveedvdv-nvidia]

Fixes #224.

The constexpr interpreter tracks the initialization of each element of a GNU vector in the initialization bitmap of the enclosing complete object (e.g., init_subobject_to_zero marks every element). However, compute_prefix_size_for_type reserved a bitmap only for class and array types, so for a complete object of vector type those bits landed in the alignment padding of the bookkeeping prefix and, for larger vectors (64 bytes suffices), before the start of the allocation. That's the out-of-bounds access ASan reports for the example in the issue.

A related problem: mark_whole_subobject_initialized and mark_whole_subobject_uninitialized treated a vector like a scalar and updated only the bit of its first element. So assigning a whole vector subobject and then reading a later element gave a spurious "access to uninitialized object" error (GCC and Clang accept it):

typedef int vi4 __attribute__((vector_size(16)));
struct T { vi4 v; };
constexpr int f() { T t; t.v = vi4{1, 2, 3, 4}; return t.v[3]; }
static_assert(f() == 4, "");

and reading an element of a vector member after destroying it (s.v.~vl8(); return s.v[7];) was not diagnosed (Clang rejects it).

This change adds a has_tracked_subobjects predicate (class, array, or vector type) and uses it in those three places.

Summary by CodeRabbit

• Bug Fixes
  • Fixed constant evaluation of GNU vector types so initialization and destruction are tracked across the entire vector, including vectors in structs and arrays.
  • Prevented incomplete initialization tracking that could lead to memory corruption or incorrect constant-expression results.
  • Improved detection of reads from vector elements after the vector has been destroyed, producing the expected uninitialized-object diagnostics.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: edgcpp/compiler
• Branch: fix/224
• File: .coderabbit.yaml
• Commit: 3c40d92
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 217ee1c9-4610-4df7-aba0-b6b103ab899b

Commits

Reviewing files that changed from the base of the PR and between 5984bca and 3c40d92.

Files selected for processing: 8

• src/interpret.c
• src/pending_changes/gh-224-constexpr-vector-init-bitmap.txt
• tests/tests/regressions/.gh-224-diag.rto/default.1.1.txt
• tests/tests/regressions/.gh-224-diag.rto/default.2.1.txt
• tests/tests/regressions/.gh-224.rto/default.1.1.txt
• tests/tests/regressions/.gh-224.rto/default.2.1.txt
• tests/tests/regressions/gh-224-diag.sft.cpp
• tests/tests/regressions/gh-224.sft.cpp

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Walkthrough

The constexpr interpreter now allocates initialization bitmaps for GNU vector types and tracks whole-vector initialization and uninitialization. Regression tests cover constexpr vector operations and expected diagnostics for reads after vector destruction.

Changes: GNU vector initialization tracking

Layer / File(s)	Summary
Bitmap storage src/interpret.c	A shared predicate includes GNU vectors among types that require tracked-subobject bitmap storage when GNU vector types are enabled.
Whole-vector state tracking src/interpret.c	Whole-subobject initialization and uninitialization now apply the existing bitmap tracking path to vectors.
Regression coverage tests/tests/regressions/gh-224.sft.cpp, tests/tests/regressions/gh-224-diag.sft.cpp, tests/tests/regressions/.gh-224*.rto/*, src/pending_changes/gh-224-constexpr-vector-init-bitmap.txt	Tests cover constexpr vector initialization and expected uninitialized-object diagnostics after destruction. The regression fixtures and GH #224 report are added.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested labels: bug

Suggested reviewers: nv-cmeerw

Merge Risk: Minimal · up to 3c40d

No merge-blocking issue was identified. Run the regression tests through normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely identifies the main change: constant evaluation support for GNU vector objects. It also references the relevant issue.
Linked Issues check		Issue #224 requires fixing GNU vector initialization tracking that can write outside the allocation. has_tracked_subobjects includes tk_vector, and compute_prefix_size_for_type therefore reserve…
Out of Scope Changes check		The changes stay within Issue #224. The source change updates only initialization bitmap allocation and whole-subobject tracking for classes, arrays, and GNU vectors. The pending-change report and reg…

Full details: Linked Issues check

Explanation

Issue #224 requires fixing GNU vector initialization tracking that can write outside the allocation. has_tracked_subobjects includes tk_vector, and compute_prefix_size_for_type therefore reserves the bitmap for complete vector objects. The same predicate makes whole-vector initialization and destruction update all element states. The added gh-224.sft.cpp and diagnostic regression tests cover 64-byte vectors, vector subobjects, whole-vector assignment, and post-destruction element reads.

Full details: Out of Scope Changes check

Explanation

The changes stay within Issue #224. The source change updates only initialization bitmap allocation and whole-subobject tracking for classes, arrays, and GNU vectors. The pending-change report and regression tests document and verify the reported vector failures. No unrelated behavior is changed.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[dkolsen-pgi]

Looks good.

Good job finding the bug of not marking the whole object as initialized or uninitialized. I ran across that while debugging the problem, but didn't realize that it was incorrect.