"Tim Peters" <tim.one@comcast.net> writes: > > As the real problem is wide-spread, > > By my meaning of "real problem", as I've said before I doubt there are many > instances of it. That might be. What they consider wide-spread is the assumption that you can access the same memory with different incompatible struct types. Atleast the Linux kernel is known to miscompile because of this assumption. Whether most of the programs that are incorrect in this respect also give an opportunity for the optimizer to generate bad code, I don't know. Reportedly, the typical problem is not a bad write order, but a failure to reload a value that the compiler "knows" not to be changed. > In the comparisons it's complaining about, casting the comparands to char* > first would yield standard-conforming code with the semantics we intend. Yes. Indeed, gcc 3.3 offers a type attribute "may_alias", which causes a type to be treated like char* for aliasing purposes. I still think that the non-standards-compliance for Python should be removed in 2.4. If we ever get a bad optimization because of aliasing problems, it will be very time consuming to find the real cause of the problem. So the problem is best avoided to begin with. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4