https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127049

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Claude says:

coords is forced to 64-byte alignment, which also pulls alignof(LeafBucket) up
to 64. sizeof(coords) = 3·32·4 = 384 bytes, so each row coords[d] sits at
offset d*128 from the struct base — 0, 128, 256 — all multiples of 64. ids adds
128 bytes, giving sizeof(LeafBucket) = 512, itself a multiple of 64, so there's
no interior or tail padding surprise. std::vector<LeafBucket> allocates through
the C++17 aligned-new path since libstdc++'s std::allocator honors
over-alignment, so buckets.data() really is 64-aligned — that part isn't in
question.

The fault is downstream of inlining. b.build(0, 3, 0, 1) is a single call site
with all-literal arguments and B=1, so node_idx >= B-1 is trivially true and
the whole thing collapses to straight-line code with size constant-propagated
to 3. The "already filled" loop runs i ∈ [0,3); the padding loop — the one that
faults — runs i ∈ [3,32). The inner d-loop (trip count 3) almost certainly gets
fully unrolled, so what the vectorizer actually sees is three independent store
streams, one per row, each indexed by i with IV start value 3. For row d, the
store address is base + d*128 + i*4; at i=3 that's base + d*128 + 12, and since
d*128 mod 16 == 0 for all three rows, every one of them is base+12 (mod 16) —
exactly matching the reporter's %rdx % 16 == 12.

So this isn't "the vectorizer got confused about alignas(64)" in isolation —
coords[d] genuinely is 64-byte aligned as an array. The bug is that whatever
alignment-analysis path decided to emit movaps folded in the field's static
alignment (64) but dropped the constant contribution of the loop's initial IV
value (the +12 from i starting at 3, itself only known post-inlining/constprop)
when computing the DR's actual misalignment. That's consistent with a
vect_compute_data_ref_alignment/dr_misalignment-class bug rather than anything
target-specific — i386.md just faithfully turns "vectorizer says aligned" into
movaps.

Reply via email to