The asker has AVX2 intrinsics code that compiles and runs correctly under both MSVC and Intel ICX 2025.2 at maximum optimization. The moment they drop to /Ob1 (inline only functions marked __inline), the debugger reports a read access violation on a pointer that is demonstrably valid. Maximum-inlining builds are fine; selective-inlining builds blow up at runtime under the MSVC IDE debugger.

This sits in a particularly nasty corner of the toolchain stack: a third-party compiler (ICX, which is LLVM-based) producing PDB-format debug info consumed by Microsoft's debugger, generating SIMD instructions whose correctness depends on stack alignment guarantees that differ between inlined and out-of-line call sites.

Why this is interesting: AVX2 aligned loads (_mm256_load_si256, VMOVDQA) require 32-byte alignment. The Windows x64 ABI only guarantees 16-byte stack alignment at function entry. When a function is inlined, the compiler sees the full context and can prove (or arrange) 32-byte alignment of locals. When the same function is emitted out-of-line, the prologue must realign the stack itself, and any mismatch between what the caller promised and what the callee assumed produces a fault on the first aligned 256-bit load. The "invalid pointer" message is misleading — the pointer value is fine; its low 5 bits aren't.

Direction toward a solution:

• Look at the disassembly at the faulting instruction. If it's VMOVDQA / VMOVAPS / VPADD* against a memory operand, suspect alignment. Switch to _mm256_loadu_si256 (unaligned) at the suspect site as a diagnostic — if the crash disappears, you've confirmed it.
• Check __alignof the offending object and whether it's a stack local, heap allocation, or a struct member. Heap allocations from malloc are only 16-byte aligned on Windows; use _mm_malloc(size, 32) or _aligned_malloc.
• Compare the prologue ICX generates at /O2 versus /Ob1 for the non-inlined function. ICX may be emitting and rsp, -32 only in one configuration.
• File against Intel — ICX 2025.2 has had several reported AVX codegen regressions around inlining heuristics, and a minimal repro on the Intel oneAPI forum often gets faster traction than SO.

Gotchas: The MSVC debugger's exception text is canned; "access violation" covers both bad pointers and alignment faults (#GP from misaligned VEX.128/256 aligned ops). Don't trust the message. Also, debug-vs-release struct layout can differ if any member uses __declspec(align) alongside compiler-inserted guard bytes.