Comment by dellorter
3 years ago
If you overlay a struct in your (char) buffer and dereference a pointer to it you would be accessing something with a different type than its declared type(char* as struct something *), it’s strict aliasing violation
To do stay in the rules you could set up a void* to suitable region in a linkerscript
Welp. Linus Torvalds was right about this stuff.
https://lwn.net/Articles/316126/
https://lkml.org/lkml/2003/2/26/158
Wait until someone tells Linus about how processors do reordering.
(Yes, I know he understands it. Clearly he just refuses to accept that compilers can also reorder his code and he needs to accommodate that.)
Processors doing out-of-order execution doesn't change the semantics of the code. That's very different from the example where gcc just throws away the assignment.
The idea that he just needs to accommodate the compiler people is silly. Compilers exist to serve programmers, not the other way around. It's entirely reasonable to disagree with the compiler developers and use a flag to disable behaviour your don't want.
1 reply →
> he needs to accommodate that
Clearly he doesn't. He just disabled harmful features and called it a day. Stuff like strict aliasing and undefined signed integer overflow apparently do nothing but serve as an excuse for the optimizer to screw up perfectly reasonable code.
https://cellperformance.beyond3d.com/articles/2006/06/unders...
https://stackoverflow.com/q/2958633/512904
Looks like this is a pretty good approach to fixing the C language. Take the nonsensical undefined stuff and tell the compiler to define it.
Looks like there is a may_alias type attribute to tell GCC that some types may alias:
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht...
I'm not sure if it's worth the effort though. Too much uncertainty.
1 reply →
In fairness, CPU reordering is does not visibly affect a thread view of their own loads and stores.