[Martin] > ... > But gcc is pointing to a real problem. It is just that it cannot, in > general, detect the real problem. Perhaps it can't now, but it *could* know when it's reordering loads and stores, and doing so because of anti-aliasing assumptions. There simply isn't a real problem unless it's doing that (by "real problem" I don't mean a violation of a formal rule, but an actual case of code generation that doesn't match our intent). > 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. > it makes a best effort approach in guessing what programs might show > undefined behaviour. > > As it turns out, in the case of Python, the compiler is right: There > is undefined behaviour with respect to PyObject*. We could cheat the > compiler to fail to recognize our bad cade, but it still would be bad > code. In the comparisons it's complaining about, casting the comparands to char* first would yield standard-conforming code with the semantics we intend. I haven't seen a real example of anything else in Python it might be worried about (I assume Neil's example was made up), so nothing else to say about those. >> The other question is whether no-strict-aliasing prevents such >> optimizations. > It does. gcc then assumes that any pointer may alias with any other. >> If it does, then we should probably always use it. > We do. Thanks for the confirmation!
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