I've seen this happen more times than I care to admit, usually when someone is trying to squeeze every last drop of performance out of their code using SIMD (Single Instruction, Multiple Data) instructions. You write some clever assembly or use an intrinsic, you're expecting a massive speedup, and instead, the program just crashes with a segmentation fault. No helpful error message, just a dead process.

Take a look at this snippet. I'm trying to load four floats into an SSE register to do some fast math.

#include <stdio.h>
#include <immintrin.h> // For SSE intrinsics

int main() {
    float data[4] = {1.0f, 2.0f, 3.0f, 4.0f};
    
    // This intrinsic REQUIRES the memory address to be 16-byte aligned
    __m128 vector = _mm_load_ps(data); 
    
    printf("First element: %f\n", vector[0]);
    return 0;
}

The Mysterious Crash of _mm_load_ps

If you run this, it might work on your machine today, and then crash on another machine tomorrow. Why? Because `float data[4]` only guarantees that the array is aligned to the alignment of a float (usually 4 bytes). However, the _mm_load_ps instruction is "aligned load"—it explicitly tells the CPU, "I promise this data starts at a 16-byte boundary."

If the compiler happens to place data at an address like 0x...04 or 0x...08, the CPU will trigger a general protection fault. You've lied to the hardware, and the hardware doesn't take kindly to that.

Forcing the Boundary with alignas

To fix this, we need to tell the compiler that this specific piece of memory must start on a 16-byte boundary, regardless of the natural alignment of the data type. This is where <stdalign.h> comes in. It provides the alignas specifier.

Here is the corrected version:

#include <stdio.h>
#include <immintrin.h>
#include <stdalign.h> // Required for alignas and alignof

int main() {
    // We force the compiler to start this array on a 16-byte boundary
    alignas(16) float data[4] = {1.0f, 2.0f, 3.0f, 4.0f};
    
    __m128 vector = _mm_load_ps(data); 
    
    printf("First element: %f\n", vector[0]);
    return 0;
}

By adding alignas(16), the compiler will insert padding bytes before the array if necessary to ensure the address is a multiple of 16. Now, _mm_load_ps is happy, and your program is stable.

Verifying Requirements with alignof

You might be wondering, "How do I even know what alignment a type needs?" You shouldn't just guess. C11 gives us alignof for exactly this purpose. It tells you the alignment requirement of a type or a keyword.

If you're writing a library and you want to ensure your internal structures are aligned to a CPU cache line (usually 64 bytes) to avoid "false sharing" in multi-threaded code, you can use it like this:

#include <stdio.h>
#include <stdalign.h>

typedef struct {
    alignas(64) int counter;
    int padding[15]; // Fill the rest of the cache line
} ThreadStats;

int main() {
    printf("Alignment of ThreadStats: %zu\n", alignof(ThreadStats));
    // This will output 64
    return 0;
}

Just a heads-up: alignas can only make alignment stricter. You cannot use it to make a type less aligned than its natural requirement. If you try to alignas(1) an integer, the compiler will simply ignore you or throw a warning, because the hardware requires a minimum alignment for the CPU to read the value efficiently.

📋 Practical Task

Exercise: Creating a Cache-Line Aligned Data Buffer

In high-performance networking or audio processing, we often want our data buffers to align perfectly with the CPU cache lines to prevent performance degradation. Assuming a standard cache line size of 64 bytes, complete the following task:

1. Define a struct named AudioPacket that contains an array of 16 floats (representing audio samples) and a uint32_t packet ID.
2. Use alignas to ensure that every instance of AudioPacket starts on a 64-byte boundary.
3. In your main function, create an array of three AudioPacket structs.
4. Write a loop that prints the memory address of each struct in the array.
5. Verify that the difference between the addresses of consecutive structs is a multiple of 64.