For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }

LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess.

Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.

Does make me wonder what restrict-related bugs will be (have been?) uncovered in GCC, if any. Or whether the GCC devs saw what LLVM went through and decided to try to address any issues preemptively.

IIRC at least one of the `restrict` bugs found by Rust was reproduced on both LLVM and GCC.

gcc has had restrict for 25 years I think. I would hope most bugs have been squashed by now.

Possibly? LLVM had been around for a while as well but Rust still ended up running into aliasing-related optimizer bugs.

Now that I think about it some more, perhaps gfortran might be a differentiating factor? Not familiar enough with Fortran to guess as to how much it would exercise aliasing-related optimizations, though.

I think Fortran function arguments are assumed not to alias. I'm not sure if it matches C restrict semantics though.

Yeah, that's why I was wondering whether GCC might have shaken out its aliasing bugs. Sibling seems to recall otherwise, though.