Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

”even though C++ suffers from the same aliasing flaws C has.”

C no longer has them. Not since a standard that’s 20 years old (C99). restrict qualifier handles that.

Unfortunately C++ committee has not included restrict in C++, but it is available in all major compilers as an extension.



C absolutely has them, you can opt out of aliasing on an individual basis but aliasing flaws are the default.

So much so that rustc regularly has to disable their noalias annotations because its pervasive noaliasing exercises rarely used LLVM paths and leads to miscompilation. Outputting noalias is currently disabled again in IR generation[0][1].

Note from downthread comments in [1] that it's completely possible to create valid C code which miscompiles on both GCC and LLVM (though GCC has been fixed since), it's just unlikely that a regular C dev would write the mix of unrolled loops, inlined functions and restrict annotations which triggers the issue.

[0] https://github.com/rust-lang/rust/issues/54462

[1] https://github.com/rust-lang/rust/issues/54878


restrict is so rarely used that optimizations based on non-aliasing data are broken in both major compilers. A fact which has bitten Rust repeatedly.


FWIW the last round was an issue with the interaction between noaliasing and loop unrolling (after inlining) as unrolling would fail to "split" the noalias between unrolled iteration, so it was not the noalias handling which was broken but the loop unrolling pass.

And my understanding's it's since been fixed in GCC.

I don't doubt for a second there will be new miscompilations discovered after that one's fixed though.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: