> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Yeah. That's sad but there's nothing that can be done about it. If you write C you're basically guaranteed to violate strict aliasing at some point and I just cannot handle the uncertainty anymore. The Linux kernel developers are much smarter than me and as far as I know they reached the same conclusion as I did: this aliasing stuff is not even worth enabling.

I know there's a may_alias attribute you can apply to pointers to warn the compiler but I'm not confident in my ability to do it 100% correctly. I have a feeling it'd end up getting applied to a significant chunk of the code anyway, might as well just turn it off.

> char is allowed to alias other types.

I know. But can uint8_t? It's basically the same type as unsigned char but it's still a distinct type in the compiler's eyes. Never found a definitive answer to that question. What if you define your own u8 type?

I know for a fact uint16_t can't safely alias anything. Implementing a 16 bit hash function? Hoping to just treat an arbitrary buffer as an array of u16? Not gonna happen unless you turn off this aliasing nonsense.

> Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

I shouldn't have to copy huge buffers all over the place just to get the compiler to generate the simple instructions I want. This is on the same level as the "pointer laundering" advice I've received. Oh just pass the pointer through some inline assembly, compiler can't see into it so it assumes anything can happen and it won't screw up the code trying to optimize. This memcpy is just yet another thing the compiler can't see into. The proper solution is to kill the problematic optimizations.

> No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

It doesn't have to be that way. I statically link all my code, enable link time optimization, pass flags like -fwhole-program. Surely the compiler can analyze the entire program and statically determine that certain pointers do not alias.

I have a memory allocator that works with a huge statically allocated byte buffer as its backing memory. Surely the compiler can determine that all pointers returned by my memory allocation functions are subsets of that buffer and that they do not necessarily alias each other.

> use flags to change the language semantics to your taste

That's exactly what I was advocating for in my post.

> That doesn't make the default semantics bad though.

I would argue that they are extremely bad. Compilers will straight up delete overflow and null checks from your code if the conditions are right. This can cause it to "optimize" entire functions into literally nothing. There's just no way anyone can convince me that this is not adversarial, if not malicious.

> Then C and C++ are simply not made for you.

C was made to support the development of Unix. I'm writing similar low level Linux operating system stuff. I'd say I'm closer to the target audience than all these speed obsessed folks ever were.

> There are plenty of "safe" languages for people who don't care about the perfomance impact.

I absolutely do care about performance in general.

I said I don't care about the performance impact of that one flag. Adding that flag buys me the certainty that the compiler won't screw the code up based on absolute nonsense assumptions that I don't ever want it to make. I've made the decision to not care in this case. I absolutely do want all the other optimizations the C compilers will give me.

And I don't want "safe", I want "sane".

Things like signed integer overflow not being C's particularly idiotic "can't ever happen, please delete any checks" flavor of undefined falls under my definition of "sane". I also consider overlaying a structure on top of a byte buffer to be such a basic operation there's no point in using C at all if the compiler is gonna screw this up.

> Try -O0.

No. That disables too many useful optimizations that are not problematic in any way whatsoever.