Here's GCC 8 providing diagnostics (see also -vec-all) $ g++ -march=haswell -Ofast -fopt-info-vec-missed x.C -c x.C:8:23: note: interleaved store with

Here's GCC 8 providing diagnostics (see also -vec-all) $ g++ -march=haswell -Ofast -fopt-info-vec-missed x.C -c x.C:8:23: note: interleaved store with gaps x.C:8:23: note: not vectorized: complicated access pattern. x.C:8:23: note: bad data access. x.C:8:23: note: not vectorized: not enough data-refs in basic block. x.C:12:41: note: not vectorized: no grouped stores in basic block. x.C:8:23: note: Build SLP failed: unrolling required in basic block SLP x.C:8:23: note: Build SLP failed: unrolling required in basic block SLP x.C:14:3: note: not vectorized: not enough data-refs in basic block. and here's GCC nearly-9: $ g++ -march=haswell -fopt-info-vec-all -Ofast x.C -c x.C:8:23: optimized: loop vectorized using 32 byte vectors x.C:5:8: note: vectorized 1 loops in function. x.C:12:14: note: ***** Re-trying analysis with vector size 16 x.C:8:23: note: ***** Re-trying analysis with vector size 16 In addition to what others have said, you typically need "restrict" on array args, and -ffast-math, or at least -funsafe-math-optimizations (in -Ofast), for things like reductions. (You need -funsafe-math-optimizations for NEON generally, per GCC docs.) A BLAS-like library still passes its tests with -ffast-math. I've recently had GCC 8 get about 2/3 the performance on haswell for a generic C optimized DGEMM micro-kernel as the hand-optimized one of similar structure which uses intrinsics/assembler. Without checking, the expert expects the performance difference to be due to prefetch and unrolling, which the generic kernel doesn't leave to the compiler.